Fuel Dispenser Commerce

ABSTRACT

Systems and processes may provide for commerce at a fuel dispenser. In one general aspect, a system and process at a fuel dispenser may have the ability to present a user interface including data regarding at least one merchant remote from the fuel dispenser&#39;s fueling facility and to determine if ordering data corresponding to the remote merchant has been received. If ordering data corresponding to the remote merchant has been received, the system and process may have the ability to present a user interface regarding payment data. The system and process may also have the ability to determine if payment data has been received and, if payment data has been received, generate a message regarding the ordering data for a remote merchant computer.

RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 14/553,336, entitled “Fuel Dispenser Commerce,”filed on Nov. 25, 2014, which is a continuation application of U.S.patent application Ser. No. 11/559,199, entitled “Fuel DispenserCommerce,” filed on Nov. 13, 2006 (now U.S. Pat. No. 8,925,808), whichis a continuation-in-part of U.S. patent application Ser. No.10/411,524, entitled “In Dispenser Point-Of-Sale Module For FuelDispensers,” filed on Apr. 10, 2003 (now U.S. Pat. No. 7,624,042) andclaims priority to U.S. Provisional Patent Application No. 60/736,203,entitled “Fuel Dispenser Commerce,” filed on Nov. 14, 2005, which arehereby incorporated by reference in their entirety.

TECHNICAL FIELD

This disclosure relates generally to dispensing fuel and, in particular,to fuel dispensers at fueling facilities.

BACKGROUND

The retail petroleum industry utilizes various types of fuel dispensersfor dispensing fuel to customers. Some form of remote dispensercontroller is typically used for controlling the fuel dispensers. Thedispenser controller is often on the same premises as the fueldispensers and coupled to a store interface unit so that a siteattendant can monitor and control particular fueling dispensers from abuilding at the site (e.g., a store). The dispenser controller sendsdata signals (e.g., commands) to the fuel dispensers. The data mayinclude price, payment data for the fuel dispensed, preset amounts offuel to dispense, and authorization to dispense fuel. The fueldispensers likewise send data signals to the controller, including pumpnumber, pump status, and dispensed fuel volume and sale value.

An example of one type of service that a controller commonly provides toa fuel dispenser is point-of-sale (POS). POS services may, for example,include cash register, dispenser control, credit card, inventorymanagement, processing, and scanning. POS services are commonlyimplemented in a dispenser controller utilizing an open architecturehardware platform with POS application software programming to integratethe services. Unfortunately, the communication system coupling thedispenser controller and the fuel dispensers is not particularly faulttolerant. Thus, the communications between a dispenser controller and afuel dispenser are often interrupted, leading to a loss of ability toprovide services to the fuel dispenser (e.g., financial transactions andpump functions). The fuel dispensers may, in fact, be inoperable forappreciable periods of time and not able to achieve their primaryfunction (i.e., dispensing fueling), which can be an inconvenience tocustomers and a lost source of revenue to retail fueling facilities.

SUMMARY

Systems and processes may provide for commerce at a fuel dispenser. Inone general aspect, a process performed by a fuel dispenser at a fuelingfacility may include presenting a user interface including dataregarding at least one merchant remote from the fueling facility anddetermining if ordering data corresponding to the remote merchant datahas been received. The data regarding a remote merchant may, forexample, include merchant product data. The process may also includepresenting a user interface regarding payment data if ordering datacorresponding to the remote merchant data has been received, determiningif payment data has been received, and generating a message regardingthe ordering data for a remote merchant computer if payment data hasbeen received. The process may be performed by a machine, a processorimplementing instructions, or any other appropriate device.

In certain implementations, the process may include determining whetherthe payment data is acceptable if payment data has been received.Determining whether the payment data is acceptable may includevalidating a portion of the payment data and/or determining whether thetransaction amount is below a predesignated amount.

The process may also include receiving a message comprising merchantdata from a remote merchant computer and/or determining whether topresent data regarding a remote merchant. Determining whether to presentdata regarding a remote merchant may include determining whether afueling session has reached a predesignated state and/or evaluating dataregarding a fueling facility customer.

In particular implementations, the user interface for presenting dataregarding at least one merchant remote from the fueling facility mayinclude data regarding two or more merchants.

Determining if ordering data corresponding to the remote merchant datahas been received may include generating a user interface for obtainingordering data regarding the remote merchant data and determining whetheruser input related to the user interface has been received.

In another general aspect, a fuel dispenser at a fueling facility mayinclude a display and a computer. The display may be operable to presenta user interface including data regarding at least one merchant remotefrom the fueling facility and to present a user interface regardingpayment data. The computer may be operable to determine if ordering datacorresponding to the remote merchant data has been receive and tofacilitate the presentation of the user interface regarding payment dataif ordering data corresponding to the remote merchant has been received.The computer may also be operable to determine if payment data has beenreceived and to generate a message regarding the ordering data for aremote merchant computer if payment data has been received.

In certain implementations, the computer may be further operable todetermine whether the payment data is acceptable if payment data hasbeen received and/or to determine whether to present data regarding aremote merchant. The computer may be operable to evaluate data regardinga fueling facility customer to determine whether to present dataregarding a remote merchant.

The fuel dispenser may also include a communication interface. Thecommunication interface may be operable to receive a message comprisingmerchant data from a remote merchant computer.

To determine if ordering data corresponding to the remote merchant datahas been received, the computer may be operable to generate a userinterface for obtaining ordering data regarding the remote merchant dataand to determine whether user input related to the user interface hasbeen received.

In a particular aspect, a process performed by a fuel dispenser at afueling facility includes receiving merchant data from a computer of atleast one merchant remote from the fueling facility, determining whetherto present data regarding a remote merchant, and presenting a userinterface including data regarding a remote merchant if data regarding aremote merchant should be presented. The process also calls fordetermining if user-input regarding the remote merchant data has beenreceived and generating a user interface for obtaining ordering data ifuser input regarding the remote merchant data has been received. Theprocess additionally calls for determining whether ordering data hasbeen received, presenting a user interface regarding payment data ifordering data has been received, determining if payment data has beenreceived, determining whether the payment data is acceptable if paymentdata has been received, and generating a message regarding the orderingdata for a remote merchant computer if the payment data is acceptable.

Systems and processes for fuel dispenser commerce may have one or morefeatures. For example, users may be able to use their downtime whilefueling their vehicles to order goods and/or services from remotemerchants. This may prove quite beneficial for busy customers. Moreover,it may provide another advertising and revenue stream to merchants. Asanother example, ordering and payment for goods and/or services of aremote merchant may occur even if some of the fueling facility'scomponents are temporarily unavailable. Thus, the systems and processesmay have robustness. As an additional example, retail fueling facilitiesmay be provided with another revenue stream, through, for example,advertising and sales-revenue sharing from the remote merchants.

The details of one or more implementations are set forth in theaccompanying drawings and the description below. Other features will beapparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a block diagram illustrating one implementation of a systemfor fuel dispenser management.

FIG. 2 is a block diagram illustrating one implementation of a fueldispenser for fuel dispenser management.

FIG. 3 is a flow chart illustrating one implementation of a process forfuel dispenser management.

FIG. 4 is a block diagram illustrating another implementation of asystem for fuel dispenser management.

FIG. 5 is a block diagram illustrating a detailed implementation of thesystem of FIG. 4.

FIG. 6 is a block diagram illustrating a particular implementation of afuel dispenser for the system of FIG. 4.

FIG. 7 is a block diagram illustrating another implementation of a fueldispenser for the system of FIG. 4.

FIG. 8 is a block diagram illustrating still another implementation of afuel dispenser for the system of FIG. 4.

FIG. 9 is a flow chart illustrating one example of a process for fueldispenser management.

FIG. 10 is a block diagram illustrating one implementation of a retailfueling facility system having fuel dispenser management.

FIG. 11 is a block diagram illustrating an example network system forfuel dispensers.

FIG. 12 is a block diagram illustrating one example of a fuel dispenserfor fuel dispenser management.

FIG. 13 is a flow chart illustrating one example of a process forcoordinating fuel dispensers.

FIG. 14 is a flow chart illustrating another implementation of a processfor managing a fuel dispenser.

FIG. 15 is a flow chart illustrating another example of a process formanaging a fuel dispenser.

FIG. 16 is a block diagram illustrating a system for fuel dispensercommerce.

FIG. 17 is a block diagram illustrating one example of a systemcomponent for fuel dispenser commerce.

FIG. 18 is a flow chart illustrating a process for fuel dispensermanagement.

Like reference symbols in the various drawings indicate like elements.

DETAILED DESCRIPTION

Safety, reliability, and efficiency for fueling facilities may beimproved by intelligent control of fuel dispensers. These benefits mayapply not only to the actual dispensing of fuel at a fuel dispenser, butalso to the customer to which the fuel is being dispensed. In particularimplementations, a fueling facility process and/or system may includethe ability to provide enhanced safety, reliability, and/or efficiencyby providing enhanced management at one or more fuel dispensers. Theenhanced management may, for example, provide point-of-sale functions,fuel dispenser coordination, fuel dispenser diagnostics, data security,and sales capabilities for remote merchants. Other implementations mayinclude one or more of these features as well as additional features.

FIG. 1 illustrates one implementation of a system 100 for fuel dispensermanagement. As illustrated, system 100 represents a retail fuelingfacility, and could be representative of a gas station environment, aconvenience store environment, or any other appropriate type of retailfueling facility.

System 100 includes fuel dispensers 110, a facility controller 120, acommunication network 130, and a store interface unit 140. Fueldispensers 110 are operable to dispense fuel (e.g., gasoline, diesel,liquid propane, or ethanol) to customers at system 100, typically underat least partial control of facility controller 120. Communicationnetwork 130 allows facility controller 120 to communicate with fueldispensers 120. Communication network 130 also allows fuel dispensers110 and facility controller 120 to communicate with store interface unit140. Store interface unit 140 is also operable to provide controlfunctions to fuel dispensers 110.

In more detail, fuel dispensers 110 may be fuel dispensers, pumps, orany other appropriate fuel dispensing apparatuses. Fuel dispensers 110may have single or multiple hose configurations. Depending on theirconfiguration, fuel dispensers 110 may dispense one or more products(e.g., gasoline and diesel). Fuel dispensers 110 typically operate incooperation with facility controller 120 and store interface unit 140 todispense fuel. In doing so, a fuel dispenser may recognize when acustomer is present (e.g., by detecting activation of an input device orremoval of a pump handle) and notify facility controller 120, which maythen obtain payment information from the customer, authenticate thecustomer, and allow fuel dispensing to begin. The fuel dispenser mayalso communicate the dispensed amount of fuel to the facilitycontroller, which may complete the sales transaction when the customeris finished dispensing fuel. The fuel dispensers may, however, operateindependently of the facility controller and/or the store interface unitfor certain tasks and/or periods of time, as will be explained below.

Facility controller 120 may be a server, a personal computer, or anyother appropriate device for interacting with and controlling fueldispensers 110. Facility controller 120 typically includes a processor(e.g., a microprocessor, a microcontroller, or any other appropriatedevice for manipulating information in a logical manner) and memory(e.g., random access memory (RAM), read-only memory (ROM), compact-diskread-only memory (CD-ROM), programmable read-only memory (PROM), a harddrive, and/or any other appropriate information storage device) thatstores instructions and/or data for the processor. The instructions may,for example, include an operating system (e.g., Linux, Unix, or Windows)and applications (e.g., fuel dispenser control, accounting, anddiagnostics). Facility controller 120 may, for example, provideauthorization, financial transaction, and fuel dispensing management forfuel dispensers 110. To accomplish this, facility controller 120 mayprovide one or more operational commands to the fuel dispensers. Inparticular implementations, a processor may be a single or dual 32-bitprocessor operating at 600 MHz, and memory may include 512 MB of mainmemory and 4 GB of storage. The facility controller may be located in orexternal to a store at a fueling facility.

Communication network 130 allows fuel dispensers 110 and facilitycontroller 120, as well as store interface unit 140, to communicate witheach other. Communication network 130 may operate according to anyappropriate communication technique, including wireline (e.g., IEEE802.3 or RS-232), wireless (e.g., IEEE 802.11, CDMA 2000, or GPRS), oroptical (e.g., FDDI or SONET). Communication network 130 may include oneor more components for facilitating communication, such as hubs,routers, switches, bridges, repeaters, multiplexers, and transceivers.In particular implementations, communication network 130 may operate bya combination of communication techniques.

Communication network 130 is coupled to fuel dispensers 110, facilitycontroller 120, and store interface unit 140 by communication links 150.Communication links 150 may be wireline (e.g., twisted pair wire orcoaxial cable), wireless (e.g., radio frequency (RF) or infrared (IR)),optical (e.g., fiber-optic cable), and/or any other appropriate path forconveying information. In particular implementations, communicationlinks 150 may include a combination of communication link types (e.g.,wireline and wireless).

Store interface unit 140 may be a server, a personal computer, a dataterminal, or any other appropriate device for interacting with fueldispensers 110 and/or facility controller 120. Store interface unit 140may include a processor and memory that stores instructions and/or datafor the processor. Store interface unit 140 also typically includes auser input device (e.g., a keypad, a keyboard, a touch screen, and/or apointing device) and a display device (e.g., a CRT or LCD monitor).Store interface unit 140 may, for example, allow a store attendant toprovide authorization and financial transaction services for fueldispenser 110. To accomplish this, the store interface unit may provideoperational commands (e.g., dispense fuel, reserve for specific monetaryamount, or print receipt) to the fuel dispensers. Store interface unit140 may operate in conjunction with facility controller 120 to providethese services.

In one mode of operation, when one of fuel dispensers 110 detects thepresence of a facility customer (e.g., by detecting removal of a pumphandle, activation of a user input device, insertion of a payment card,or presence of a customer identifier), the fuel dispenser issues anotification to facility controller 120. Facility controller 120 maythen determine the technique by which the customer plans to pay for thefuel to be dispensed (e.g., pay at the fuel dispenser or pay in thestore). If the customer indicates that she is planning to pay at thefuel dispenser, the facility controller may request that the customerpresent a customer identifier (e.g., a payment card or an RFID tag)before allowing the customer to dispense fuel. If the customer indicatesthat she is planning to pay in the store, the facility controller maynotify the store attendant and allow the store attendant to make adecision regarding whether fuel should be dispensed.

In the case that the customer indicates she is planning to pay at thefuel dispenser, the facility controller may prompt the fuel dispenser torequest presentation of the customer identifier. The fuel dispenser maythen wait for presentation of the customer identifier (e.g., insertionof a payment card) and read the information contained thereon.

Typically, at least some customer identification data is sent from thefuel dispenser to facility controller 120. The facility controller maythen determine the validity of the customer identifier. Determining thevalidity of the customer identifier may include performing a checksum ofthe data received therefrom or contacting the issuer of the customeridentifier to determine whether the customer identifier is valid. Also,the facility controller may check the authorization of the customeridentifier. For example, the facility controller may contact a paymentcard issuer to determine the credit limit of a payment card.

If the facility controller determines that the customer identifier isvalid and/or authorized, the facility controller may activate the fueldispenser, which may then dispense fuel to the customer. While fuel isbeing dispensed, the fuel dispenser may provide the facility controllerwith data regarding the dispensing (e.g., type of fuel being dispensedand amount of fuel being dispensed). When the customer is finisheddispensing fuel (e.g., indicated by replacement of the pump hand), thefacility controller may determine a total price for the dispensed fueland seek approval for the total price. Once approval has been granted,the facility controller may cause a receipt to be printed for thecustomer.

In certain modes of operation, however, one or more of fuel dispensers110 may be able to operate independently of facility controller 120, atleast for a certain functions and/or periods of time. This may beespecially advantageous if facility controller 120, communicationnetwork 130, and/or communication links are prone to failure, which theyoften are.

As one example of independent operation, fuel dispensers 110 may includethe ability to provide point-of-sale (POS) operations. That is, thecustomer may purchase fuel from a fuel dispenser without it having to bein contact with the facility controller or the store interface unit.Thus, if facility controller 120, communication network 130, and/orstore interface unit 140 is inoperative, the fuel dispenser may continuedispensing fuel. To accomplish this, a fuel dispenser may, for example,be able to provide appropriate interaction with a customer (e.g.,request customer identifier) and perform authentication operations forcustomer identification data (e.g., checksums). Not all authenticationoperations, for PINs, for example, in some implementations, may be ableto be performed. The fuel dispenser may also be able to recorddispensing and financial aspects of a fueling session and provideappropriate commands to the fuel dispenser's components. The recordeddispensing and financial data may be provided to the facility controllerfor operations management and account reconciliation when communicationtherewith is reestablished.

As another example of independent operation, a fuel dispenser maydetermine how to handle data (e.g., from the customer identifier). Forexample, if a portion of data is to be sent to the facility controllerand the fuel dispenser can communicate with the facility controllerthrough more than one type of communication link (e.g., wireline andwireless), the fuel dispenser may determine which communication link touse to covey the data portion. For instance, some wireless techniques(e.g., IEEE 802.11) may be faster than some wireline techniques (e.g.,RS-422), and do not require the same type of semi-permanentinfrastructure (e.g., wires buried under concrete), but wireline linksmay provide more security (e.g., by being less accessible toeavesdroppers). The fuel dispenser may, thus, make the communicationlink determination based on the sensitivity of the type of data, whichmay have been predesignated. In particular implementations, for example,the fuel dispenser may send sensitive types of data over a wireline linkand non-sensitive types of data over a wireless link. A determinationmay also be made as to whether to encrypt the data before sending it. Asanother example, if a portion of the data is to be stored at the fueldispenser (perhaps because communication with the facility controller isunavailable), the fuel dispenser may determine whether the data shouldbe encrypted. The fuel dispenser may, for example, make thedetermination based on the sensitivity of the type of data. Encrypting adata portion may be accomplished by any appropriate type of encryptionscheme (e.g., public key or private key).

While FIG. 1 illustrates one implementation of a system for fueldispenser management, other implementations may have fewer, additional,and/or a different arrangement of components. For example, a system maynot have a store interface unit. As another example, the facilitycontroller may be co-located with or part of store interface unit 140.As a further example, the facility controller may be coupled to one ormore off-site computer systems (e.g., a payment card issuer or a fuelsupply system). The components and techniques discussed with respect tothis implementation may also find use in a wide variety of other typesof systems.

FIG. 2 illustrates one implementation of a fuel dispenser 200 for fueldispenser management. Fuel dispenser 200 includes a dispenser manager210, a fuel controller 220, a user input device 230, a display 240, acommunication interface 250, and a management module 260. Fuel dispenser200 may be one example of a fuel dispenser 110 for system 100.

Dispenser manager 210 is responsible for managing the operations of fueldispenser 200. To accomplish this, the dispenser manager may control theelectronic functions of fuel dispenser 200. The dispenser manager mayalso collect and maintain status information regarding the fueldispenser and report the status information to a facility controller.Dispenser manager 210 may be implemented in software, hardware, or acombination thereof. As part of its functions, dispenser manager 210 maydrive the content presented on display 240.

Fuel controller 220 controls the dispensing of fuel from fuel dispenser200. To accomplish this, fuel controller 220 may control the hydraulicelements of the dispenser necessary to carry out fuel dispensingoperations. For example, fuel controller 220 may control submersiblepumps in fuel storage tanks and fuel control valves and monitor fuelflow information via metering and reporting sub systems. Fuel controller220 may also track the volume of fuel dispensed totals by grade, drivesale progress displays on the sales/volume displays, and monitor forerrors. Fuel controller 220 may be implemented in software, hardware, ora combination thereof.

User input device 230 is coupled to dispenser manager 210 and allows acustomer of a fueling facility to interact with the fuel dispenser. Userinput device 230 may be a keypad, a keyboard, a touchpad, a touchscreen, a card reader, or any other appropriate device for allowing auser to provide an indication to the fuel dispenser. If user inputdevice 230 has portions, the portions may have static and/orrearrangeable (e.g., software programmable) functions.

Display 240 is also coupled to dispenser manager 210 and allows acustomer of a fueling facility to receive data from the fuel dispenser.Display 240 may be a cathode ray tube (CRT) monitor, a liquid crystaldisplay (LCD) monitor, a gas-plasma monitor, or any other appropriatedevice for visually presenting information. The content for display 240may be provided by a facility controller and/or management module 260.If display 240 has portions, the portions may have static and/orrearrangeable functions (e.g., software programmable). In someimplementations, the user input device and the display may work inconcert with each other (e.g., the display may present instructions ordata for the user input device and/or input from the user input devicemay correlate with data presented on the display).

Communication interface 250 is also coupled to dispenser manager 210 andallows the fuel dispenser to communicate with other components at afueling facility. Communication interface 250 may be a modem, an RS-232transceiver, a wireless transceiver, or any other appropriate device forsending and/or receiving information.

Management module 260 provides fuel dispenser 200 with the ability tooperate independently of a facility controller, at least for certainoperations and/or periods of time. These operations may, for example,allow the fuel dispenser to continue selling fuel when communicationinterface 250 is unable to send and/or receive data.

Management module 260 may access memory 270, which may be RAM, ROM,CD-ROM, and/or any other appropriate information storage device. Memory270 includes instructions 272, content 274, and logs 276. Instructions272 dictate at least some of the operations of management module 260.Content 274 may be text, graphics, images, and/or video for presentationon display 240. Content 274 may be presented in accordance withinstructions 272. Logs 276 may contain data regarding transactions(e.g., fueling sessions, financial payment, or otherwise) and errors. Byanalyzing logs 276, transactions may be recreated and analyzed, anderrors may be identified and assessed.

Management module 260 may, for example, be implemented as a rule engine.In such an implementation, instructions 272 may be rules (e.g., customerinteraction rules and transaction processing rules), content 274 maystore data for implementing the results of rules, and logs 276 may storedata for processing the rules. Rule engines typically have a set ofconditions that are precursors to a result being implemented. Theconditions may also be preconditions to other conditions. Rule enginetechniques that may be used for management module 260 include those ofJRules from ILOG, Inc. of Mountain View, Calif., Jess from SandiaNational Laboratories of Livermore, Calif., or any other appropriaterule engine scheme. Management module 260 may be implemented using oneor more programming and messaging technologies, including HTTP, TCP/IP,XML, SOAP, Universal Description, Discovery and Integration (UDDI),Microsoft .NET, or Java.™. Portions of the module, for example, may bewritten in C++ in combination with other programming technologies (e.g.,.NET) or any other appropriate technologies.

In one mode of operation, dispenser manager 210 operates under thecontrol of a facility controller while the dispenser manager is able tocommunicate with a facility controller. Management module 260 may standby in a passive mode during this time. The facility controller mayprovide content to be displayed on display 240, handle point-of-saletransactions (e.g., verify and charge credit cards), and provide anyother appropriate services to the fuel dispenser.

When dispenser manager is unable to communicate with a facilitycontroller, however, management module 260 may perform one or moreduties of the facility controller. For example, management module 260may provide content 274 to display 240. The content may, for example,allow a user to interact with fuel dispenser 200 to initiate andcomplete a fueling session (e.g., by providing customer instructions),the fueling facility to provide advertising at fuel dispenser 200, orany other appropriate operation. The content may be provided accordingto instructions 272. For instance, content to initiate a fuelingtransaction may be provided when an indication that a customer hasinteracted with the fuel dispenser has been detected.

As another example, management module 260 may provide processing for thefinancial transaction required for a fueling session (e.g., a POStransaction), allowing the fuel dispenser to dispense fuel even if thefacility controller or communication network are inoperative. POSservices could include cash register, dispenser control, transactioncard processing, and/or bar code scanning.

For instance, the management module may determine whether to initiate afueling session and, if a fueling session is to be initiated, to recordthe pertinent portions of the transaction (e.g., time of day, creditcard number, current price, purchased quantity, and purchased amount).The pertinent portions of the transaction may be recorded in logs 276.In determining whether to initiate a fueling session, management module260 may validate customer identification information (e.g., byperforming a checksum) and may determine whether the fuel dispenser isstill allowed to dispense fuel. For example, the fuel dispenser may beallowed to independently dispense fuel for a certain amount of time(e.g., six hours), for a certain number of transactions (e.g.,twenty-five) for a certain quantity of fuel (e.g., five-hundredgallons), and/or for a certain purchase amount (e.g., one-thousanddollars). For specific transactions, the fuel dispenser may determinewhether the customer identification data is valid and/or limit thetransaction to a certain amount (e.g., fifty dollars). Thedeterminations may occur according to instructions 272.

The management module may also generate representations of appropriatedispenser control signals for dispenser manager 210. For example,substitutes for customer activated terminal (CAT) and pump commands,which are normally sent from the facility controller, could be provided.

When dispenser manager 210 is again able to communicate with thefacility controller, management module 260 may download the transactiondata from logs 276. The facility controller may then process thefinancial data and send the data to the appropriate entity (e.g.,payment card issuer or electronic clearing house (ECH)) for completionof the financial transaction. The facility controller may also updateits information regarding the fueling facility (e.g., amount of fuelremaining).

In certain modes of operation, the management module may also be activewhile the fuel dispenser is communicating with a facility controller.Types of services that the management module may provide include POS,fuel dispenser coordination, fuel dispenser diagnostics, data security,and sales capabilities for remote merchants. POS functions, which werediscussed above, may, for example, be provided at a fuel dispenser on afull time, or close to full time, basis.

For fuel dispenser coordination, the management module may generatemessages for other fuel dispensers at the fueling facility to assist itin the fuel dispenser's operations. For example, the management modulemay request another fuel dispenser to image an area in the vicinity ofthe management module's fuel dispenser. The image may then be sent tothe requesting management module for storage and later destruction,analysis, and/or communication. As another example, the managementmodule may request another fuel dispenser to perform acustomer-interaction function for the management module's fueldispenser. For instance, the management module may request another fueldispenser to receive data (e.g., a customer payment card) or output data(e.g., print a receipt) for the fuel dispenser. If POS services areunavailable from a central component (e.g., a facility controller), thefuel dispensers may coordinate their operations to appropriate levels(e.g., dispense no more than 500 gallons or $1,000). The ability tocoordinate fuel dispensers will be discussed further below.

As one example of fuel dispenser diagnostics, the management module maydetermine whether a detected condition requires a response andfacilitate the response. Conditions that could necessitate a responseinclude environmental, mechanical, electrical, and/or logicalinstruction conditions, such as, for example, temperature, pressure,humidity, fuel leaks, open panels, dispenser intrusion, powerirregularities, watchdog timer expiration, or software exceptions.Facilitating a response could include restarting the fuel dispenser,shutting down the fuel dispenser, downloading instructions for the fueldispenser, and/or generating notifications for other components at thefueling facility. The ability to perform fuel dispenser diagnostics willbe discussed further below.

For data security, the management module may determine which, if any,data to apply security measures (e.g., encryption or routing) to. Acustomer's financial data (e.g., credit card number, PIN, etc.) is oneexample of data that may require a security measure. The securitymeasure may safely store the data at the fuel dispenser and/or convey itto another facility component (e.g., the facility controller). Theability to provide data security will be discussed further below.

As one example of providing sales capabilities for remote merchants, themanagement module may allow a fuel dispenser to market and sell thegoods and/or services of remote merchants, which may be coupled to thefuel dispenser through a communication network. The remote merchants maybe any appropriate sellers of goods and/or services.

To provide the sales capabilities, the remote merchants may downloaddata to the fuel dispensers before (e.g., at one or more times duringthe day) and/or during customer interaction therewith (e.g., when acustomer indicates interest in a product or service). The data mayinclude information regarding a merchant's products and/or services,ordering information, and/or delivery information. The fuel dispensermay be responsible for handling the interactions with the customer(e.g., presenting merchant data, obtaining order and paymentinformation, and verifying payment data), or a merchant computer (e.g.,a Web server) may assist the fuel dispenser with one or more of theseoperations (e.g., obtaining payment information and verifying paymentdata). The ability to provide sales capabilities for remote merchantswill be discussed further below.

In certain implementations, management module 260 may be responsible forproviding messages (e.g., commands and/or data) to dispenser manager 210to accomplish the module's operations. For example, the managementmodule may forward or replace messages (whether in the form ofstructured messages, unstructured messages, or signals) from a remotecomputer (e.g., a facility controller). The management module may, forinstance, receive a command message from a remote computer and determinethat the message should be provided to the dispenser manager 210 in anunaltered state. This may, for example, occur when the fuel dispenser isoperating in a normal mode and the message relates to normal operations.The management module 260 may, thus, pass the message through to thedispenser manager. As another example, the management module 260 mayhave one or more particular techniques for communicating with thedispenser manager and, thus, replace a message from a remote computerwith a message that accomplishes the same function. As a furtherexample, the management module 260 may determine that it desires thefuel dispenser to perform a function and issue a message to thedispenser manager 210 in furtherance of performance of the function. Forexample, substitutes for customer activated terminal (CAT) and pumpmessages, which are normally sent from a facility controller, could beprovided.

Although FIG. 2 illustrates one implementation of a fuel dispenser,other fuel dispenser implementations may include fewer, additional,and/or a different arrangement of components. For example, a fueldispenser may not include content, as it may not be required forcustomer operation of the fuel dispenser. As another example, a fueldispenser may include a number of displays and user input devices,especially if the fuel dispenser has multiple dispensing sides. As afurther example, memory for the management module may be shared withmemory for the dispenser manager. Moreover, the memory for themanagement module may have various forms and/or arrangements.

FIG. 3 illustrates one implementation of a process 300 for fueldispenser management. Process 300 may, for example, illustrate one modeof operation for one of fuel dispensers 110 in system 100.

Process 300 begins with waiting until a customer desires to initiate afueling session (operation 304). Determining whether a customer desiresto initiate a fueling session may, for example, be accomplished bydetecting the removal of a pump handle, the activation of a keypad, orthe insertion of a payment card.

When a customer desires to initiate a fueling session, process 300 callsfor determining whether communication with a facility controller isavailable (operation 308). Determining whether communication with afacility controller is available may, for example, be accomplished bydetermining whether a facility controller responds to status requests.If communication with a facility controller is available, process 300continues with placing a module responsible for determining whether todispense fuel in a passive state (operation 312) and generating signalsregarding initiation of a fueling session (operation 316). The modulemay, for example, be a point-of-sale module, and the signals mayindicate to a facility controller that a customer desires a fuelingsession.

Process 300 continues with receiving command signals regardingdispensing fuel (operation 320). These signals may, for example, includeinformation regarding retrieving payment data from a customer anddispensing authorization. Process 300 also calls for dispensing fuel(operation 324) and generating signals regarding the fueling session(operation 328). The signals may, for example, indicate the fueldispenser status (e.g., pumping) and the status of the session (e.g.,amount of fuel dispensed). Process 300 also includes determining whetherthe fueling session is complete (operation 332). Determining whether thefueling session is complete may, for example, be accomplished bydetecting that a pump handle has been replaced, the activation of akeypad, or any other appropriate session completion indication.

If the fueling session is complete, the process calls for returning towait until a customer desires to initiate a fueling session (operation304). If, however, the fueling session is not complete, the processcalls for continuing to dispense fuel (operation 324).

When a customer desires to initiate a fueling session and communicationwith a facility controller is not available, process 300 calls forplacing the module responsible for determining whether to dispense fuelinto an active state (operation 336) and determining whether to dispensefuel to the customer (operation 340). Determining whether to dispensefuel may, for example, be accomplished by requesting customeridentification data from the customer and analyzing the data todetermine whether it is acceptable. For instance, an error check (e.g.,checksum) could be performed on the customer identification data. Asanother example, the fuel dispenser could determine whether it is stilloperating within one or more pre-established guidelines (e.g., dispenseno more than five-hundred gallons of fuel when module is active).

If fuel should not be dispensed to the customer, process 300 calls forreturning to wait until a customer desires to initiate a fueling session(operation 304). If, however, fuel should be dispensed to the customer,process 300 calls for dispensing fuel (operation 344). Dispensing fuelmay, for example, include generating an activation signal for a fuelcontroller. Process 300 also calls for storing data regarding thefueling session (operation 348). The data may, for example, be stored ina transaction log and could include time, date, customer identificationdata, dispensed amount, and total price.

Process 300 continues with determining whether the fueling session iscomplete (operation 352). If the fueling session is not complete, theprocess calls for continuing to dispense fuel (operation 344). If,however, the fueling session is complete, the process calls forreturning to wait until a customer desires to initiate a fueling session(operation 304).

Although FIG. 3 illustrates one implementation of a process for fueldispenser management, other processes for fuel dispenser managementcould include fewer, additional, and/or a different arrangement ofoperations. For example, a dispenser management process could includedetermining whether communication with a facility controller isavailable before determining that a customer desires to initiate afueling session. As another example, a management process may place themodule responsible for determining whether to dispense fuel in an activeor inactive state before determining whether communication with afacility controller is available. Thus, the activation or deactivationof the module may not depend on the communication status of the facilitycontroller. As a further example, a management process may generate andreceive signals regarding a fueling session numerous times before,during, and/or after a fueling session. As an additional example, amanagement process may send data stored when communication with afacility controller was not available when communication with a facilitycontroller is available.

FIG. 4 illustrates another implementation of a system 400 for fueldispenser management. System 400 includes a store controller 410,external point-of-sale (POS) equipment 420, a fuel dispenser 430, and aPOS link 444. System 400 could also include additional fuel dispensers,but one is sufficient for understanding system 400. Store controller 410and external POS equipment 420 are interconnected with fuel dispenser430 to control at least some of its operations.

Typically, a fuel dispenser within existing fueling facilities isdependent upon data transmitted to it from external POS equipment 420over POS link 444 for initiating a fueling session. External POSequipment may, for example, be part of a facility controller. Thetransmitted POS data enables POS equipment 420 to control financialtransactions and pump functions. In system 400, however, fuel dispenser430 has the ability to perform at least some POS functions on its own.For example, fuel dispenser 430 may determine whether to accept apayment card, dispense fuel if the payment card is acceptable, andrecord data for completing the billing as the fueling sessionprogresses. Thus, fuel dispenser 430 may, at least for anoperationally-significant period of time (e.g., several hours), operatein an autonomous mode from external POS equipment 420, which providesrobustness to system 400, as well as increased opportunity for fuelingtransactions for customers.

FIG. 5 illustrates a detailed view of one implementation of system 400.In this implementation, fuel dispenser 430 includes an in-dispenser POSmodule 431 that allows the fuel dispenser to conduct fueling sessions ina stand-alone mode if POS equipment 420 or POS link 444 should becomeinoperable. For example, POS module 431 may provide POS functionalities,which may include cash register, dispenser control, transaction cardprocessing, and/or bar code scanning.

Store controller 410, POS equipment 420, and fuel dispenser 430 arecoupled together via communication network 440. In this implementation,communication network 440 includes a hub 442 for distributing thecommunications between the components. POS equipment 420 generatescustomer activated terminal (CAT) and pump commands that are transmittedto fuel dispenser 430 through hub 442 via link 444. The commands may berepresented by signals, structured messages, or other appropriatetechniques by which to communicate information. Store controller 410 islinked with hub 442 via a communication link 446. System 400 alsoincludes a diagnostic and asset management system 480, which, asillustrated here, can be located in the store or elsewhere at thefueling facility. Diagnostic and asset management system 480 is alsocoupled to hub 442 via communication link 446.

Fuel dispenser 430 includes a dispenser manager 432, a pair of VGAdisplays 433 including soft keys, and controllers 434 for managingperipheral elements or a bezel. Dispenser manager 432 or POS module 431drives the content associated with the VGA display(s) 433 to provideinteraction with a customer. Bezel controllers 434 provide for andcontrol user inputs to fuel dispenser 430.

Fuel dispenser 430 also includes a dispenser computer 436. Dispensercomputer 436 controls the fuel flow aspects of fuel dispenser 430. Forexample, dispenser computer 436 may control fuel-storage-tanksubmersible pumps and fuel control valves and monitor fuel flowinformation via metering and reporting sub systems, totals by grade,errors, and the like. Dispenser manager 431 interoperates with dispensercomputer 436 to deliver commands and receive transaction data andstatus. For example, dispenser manager 432 may issue commands todispenser computer 436 over an internal communication link 437 (e.g., abus) of dispenser 430. Control, status, real-time diagnostic, errorcodes, and data may also be exchanged over communication link 437. Inaddition to controlling the fuel-flow aspects of the dispenser necessaryto carry out fuel dispensing functionalities, dispenser computer 436 mayalso drive sale progress displays on sales/volume displays of dispenser430. Dispenser manager 432 also collects and maintains status of fueldispenser 430 and reports the status information to store controller 410and/or POS equipment 420.

POS module 431 is associated with dispenser manager 432 within fueldispenser 430 and provides a fault-tolerant architecture, assuringdispenser functionality in the event that POS equipment 420, HUB 442, orlink 444 crashes, goes off-line, or otherwise become unavailable. Toaccomplish this, POS module 431 is operable to perform the relevant POSfunctionalities for operating fuel dispenser 430 in an autonomous modefor at least some operationally-significant period of time (e.g., twohours). These functionalities include, but are not limited to,store/forwarding, transaction logging, and URL and payment cardprocessing. These functionalities may be a subset of the functionalitynecessary to operate a fuel dispenser on a longer-term basis, which mayreside in POS equipment 420.

To assist it with its operation, POS module 431 accesses a number ofdatabases 439 stored within a memory 438 of fuel dispenser 430.Databases 439 include data for operating POS module 431 in thestand-alone mode. This data could include, but is not limited to, URLs439 a or display content including customer instructional prompts,fueling status information, advertisements, various business rules 439 b(including fuel prices, tender media authorization information, pumpoperational rules, etc.) for operation of the POS module, and completedtransaction and error logs 439 c.

System 400 provides a variety of features. For example, due to thenetworking and POS functionality available in the fuel dispenser, thesystem is able to be implemented with standardized networkingtechnologies. Thus, distribution boxes, third-party interface boxes, andthird-party POS intermediaries may be eliminated. Additionally, itprovides the basis for an in-dispenser ordering kiosk.

Although FIG. 5 illustrates one implementation of system 400, otherimplementations of system 400 may include fewer, additional, or adifferent arrangement of components. For example, a system may notinclude a store controller. As another example, the POS equipment may beco-located with and/or part of the store controller. As a furtherexample, a fuel dispenser may have a variety of configurations, asillustrated in FIGS. 6-8.

FIG. 6 illustrates a particular implementation of a fuel dispenser forsystem 400. The fuel dispenser in this implementation includesassociated in-dispenser POS modules 431 and dispenser managers 432. Thedispenser managers and the in-dispenser POS modules may, for example, beassociated with different sides of the fuel dispenser. Dispensermanagers 432 provide visual data to and receive indications of userinput from respective displays 433 and controllers 434. Dispensermanagers 432 may both communicate with dispenser computer 436 throughcommunication link 437 for requesting fuel and receiving fuel-relateddata.

FIG. 7 illustrates another implementation of a fuel dispenser for system400. The fuel dispenser in this implementation includes a bezelcontroller and interface 435 for receiving input to the fuel dispenser.The bezel controller and interface provides data to dispenser manager432, which may provide appropriate data to in-dispenser POS module 431.Dispenser manager 432 may communicate with dispenser computer 436through bezel controller and interface 435.

FIG. 8 illustrates still another implementation of a fuel dispenser forsystem 400. The fuel dispenser in this implementation includesassociated in-dispenser POS modules 431 and dispenser managers 432. Thedispenser managers and the in-dispenser POS modules may, for example, beassociated with different sides of the fuel dispenser. Dispensermanagers 432 receive indications of user input from respectivecontrollers 434. Dispenser managers 432 may both communicate withdispenser computer 436 through communication link 437, for requestingfuel and receiving fuel-related data.

FIG. 9 illustrates one example of a process 900 for fuel dispensermanagement. In particular, process 900 is an example of a process foroperating a POS module such as POS module 431. In process 900, POSmodule 431 remains in a passive condition while external POS equipmentis operating in normal application mode (operation 904). However, onceit is determined that the link with the external POS equipment isunavailable (operation 908), the POS module begins to operate in astand-alone condition (operation 912) until it is determined that thelink with the external POS equipment has been re-established (operation916). After the link is re-established, the POS module returns to thepassive condition (operation 904).

Although FIG. 9 illustrates one implementation of a process foroperating a POS module, other processes for operating a POS module mayinclude fewer, additional, and/or a different arrangement of operations.For example, a POS module may operate on a full time basis. This couldprovide for a scaled-back version of the facility controller describedwith respect to FIG. 1, since most POS functionalities could be handledby the fuel dispenser. As another example, the POS module may becommanded to operate while the external POS equipment is to be takenoffline, for repair or replacement. Thus, a POS module could beproactively engaged to support fueling facility operations.

FIG. 10 illustrates an implementation of a retail fueling facilitysystem 1000 having fuel dispenser management. System 1000 includes aretail fueling facility 1010 that includes two islands 1020, each ofwhich encompasses six fuel dispensers 1022. Fuel dispensers 1022 areoperable to dispense fuel received via a fluid conduit 1030 from a fuelreservoir 1040. Fluid reservoir 1040 includes storage tanks 1042 a, 1042b, 1042 c that may store fuels of different types or grades. While theforegoing components provide an infrastructure for dispensing fuel tocustomers of a retail fueling facility, in various implementations, thenumber and arrangement particulars of islands 1020, fuel dispensers1022, fuel reservoir 1040, and storage tanks 1042, for example, may bevaried or otherwise adapted for specific implementations.

Fuel dispensers 1022 provide a man-machine interface for facilitating afuel dispensing session. Fuel dispensers 1022 are described in moredetail with reference to FIGS. 11-12. Fuel dispensers 1022 on an island1020 are coupled to communicate information via a communication link1024 that is local to the island. In various implementations,communication link 1024 may be implemented using any suitablecombination of physical or non-physical links that provide a path forconveying information. For example, the communication link may be awired (e.g., unshielded twisted pair (UTP), coaxial cable, or fiberoptic cable) and/or a wireless (e.g., RF or IR) link layer and may useany suitable standard or proprietary communication protocols andinterfaces (e.g., HTTP, TCP/IP, Bluetooth, wireless local area network(WLAN), controller area network (CAN), RS-485, RS-232, universal serialbus (USB), or Ethernet). Communication link 1024 may include anyappropriate collection of devices (e.g., wires, cables, hubs,transceivers, routers, repeaters) for conveying data and may, in someinstance, be a communication network. In some implementations,communication link 1024 provides for communicating messages among fueldispensers 1022 on an island 1020. In various implementations, one ormore of fuel dispensers 1022 may be configured to generate messagesthat, when received by one or more other fuel dispensers 1022 viacommunication link 1024, cause the receiving fuel dispenser(s) toperform operations in substantial coordination with one or more fueldispensers.

Each island 1020 also includes island auxiliary equipment 1026 thatgenerally provides functionality that is specific to each island 1020and that supplements the basic fuel dispensing functions of the island.Island auxiliary equipment 1026 may optionally be controlled bycommands, such as commands generated by one of the fuel dispensers inthe same island. Examples of auxiliary equipment that may be configuredto operate at least partially dedicated to a particular island 1020include communication equipment (e.g., intercom), audio and/or videorecording or playback systems, diagnostic equipment, such as fuel spilldetectors, emergency fuel shut-off controls, theft deterrent systems,surveillance equipment, lighting, and proximity detection equipment todetect the presence and/or location of vehicles near the island. Otherequipment that may be at least partially dedicated to operationsspecific to an island 1020 may also be included in the auxiliaryequipment 1026 for a particular island 1020.

In this implementation, islands 1020 may coordinate their operations bycommunicating via a communication link 1054. Communication link 1054 maybe configured to convey messages sent by a fuel dispenser 1022 in one ofislands 1020 to equipment, such as one or more of the fuel dispensers1022, in the other island 1020. In various implementations,communication link 1054 may be implemented using any suitable wiredand/or wireless link layer and may use any suitable standard orproprietary communication protocols and interfaces. Communication link1054 may include any appropriate collection of devices (e.g., wires,cables, hubs, transceivers, routers, repeaters) for conveying data andmay, in some instance, be a communication network. In someimplementations, communication link 1054 may be part of, or otherwiseintegrated with, a communication network that includes communicationlink 1024.

Communication link 1024 and communication link 1054, respectively, mayprovide a link for transporting messages among fuel dispensers 1022within an island 1020 and/or among islands 1020. For example, a fueldispenser 1022 may communicate messages relating to its operation withone or more fuel dispensers 1022 in the same island 1020 or with one ormore particular fuel dispensers in another island 1020. These messagesmay include requests for the receiving fuel dispenser 1022 to performsome service or operation. In this way, a fuel dispenser 1022 in oneisland 1020 may communicate messages to coordinate its operation withfuel dispensers 1022 in the same island and/or in another island.

Fuel dispensers 1022 may communicate with each other in order to performa variety of operations in a coordinated manner. For example, if a fueldispenser 1022 detects a fault condition (e.g., a fuel leak or fluid inthe pan), the fuel dispenser may coordinate an appropriate response withone or more other fuel dispensers 1022. Other conditions that maytrigger a need for coordination include receiving a message from aremote device (e.g., to perform a diagnostic function), loss ofcommunication with a central computer, detection of a potentialdrive-off situation, and failure of a user-interface device.

Examples of operations that the coordinating fuel dispensers 1022 mayperform include: capturing image data from different vantage pointsusing image capture equipment controlled by the fuel dispensers, such aswhen a possible drive-off (without payment) situation is detected or afuel leak is detected; providing user interface functionality formalfunctioning fuel dispensers; activating a shut-down state in whichfuel dispensing is suspended, such as when a possible fuel leak or spillis detected; re-booting the controller in a fuel dispenser, such as whena processing fault occurs; and redundant storage of data in multiplefuel dispensers to provide for information recovery in the event of dataloss. Coordinated operations may be used to provide any of a number ofservices for a fuel dispenser as an individual entity or for two or morefuel dispensers as a group.

One example of coordinated operation involves back-up user interfaceservices. Fuel dispensers may require back-up user interface services,for example, when a printer (e.g., due to lack of paper or printermalfunction) or a card reader in a fuel dispenser is out of service. Incases where a fuel dispenser has a faulty printer, for example, the fueldispenser may complete a fuel-dispensing session by sending a request toan alternate nearby fuel dispenser to print-out a transaction receipt.This is just one example that demonstrates how fuel dispensercoordination may improve the available “up-time” of fuel dispensers,reduce costs, and enhance the quality of service perceived by customers.

The appropriate fuel dispensers for coordinating operations may bepredesignated. For example, if a fuel dispenser determines that an imageneeds to be captured of a vehicle to which it is dispensing fuel, it mayalready have the identity of one or more fuel dispensers that are ableto capture such images. As another example, if a fuel dispenser's userinterface (e.g., printer) is not working, the fuel dispenser may haveits user interactions (e.g., receipt printing) performed by a nearbyfuel dispenser.

Yet another example of coordinated operation relates to interactivehealth monitoring and diagnostic testing among fuel dispensers. In someimplementations, an idle fuel dispenser may initiate a communicationsession to monitor the health of one or more other fuel dispensers byexercising communication interfaces, exercising processing functions,and verifying the integrity of stored information. For example, aninitiating fuel dispenser may perform various predetermined healthstatus checks on a second idle fuel dispenser. The initiating fueldispenser may further receive and record the results and responses fromthe second fuel dispenser.

As an illustrative example, the fuel dispenser that initiates adiagnostic test may verify that the recorded volume of fluid dispensedby the second fuel dispenser falls within an expected range. Theexpected range may be based on recorded transactional information andthe time elapsed since the previous diagnostic check. If the recordedvalue of fuel dispensed falls outside of an expected range, then theinitiating fuel dispenser may indicate, for instance, that an equipmentor operational fault (e.g., fuel leak, memory error, or meter fault) hasoccurred. Such diagnostic health checks may be performed at regularintervals, during idle times, such as when not engaged in a fueldispensing transaction, or in response to a command input by a user.Accordingly, some implementations may provide for coordinated operationof fuel dispensers to quickly detect and accurately identify fueldispenser problems at an early stage.

In the event that the diagnostic results deviate from expected resultsor are out of permitted tolerances, the initiating fuel dispenser may beconfigured to initiate corrective action. Examples of possiblecorrective actions include: re-booting the controller on the second fueldispenser; sending a command instructing the second fuel dispenser todisplay, on its user interface, a message to indicate that functionalityis currently limited or modified (e.g., “This printer is currently outof service. Your receipt will be printed at fuel dispenser #4.” or“Credit card reader is currently out of service. Please swipe yourcredit card at fuel dispenser #8, or see the cashier.”); and generatinga maintenance request message to trigger maintenance of the second fueldispenser.

Certain implementations may require fuel dispensers to authenticatethemselves to each other before coordinated operations can take place.Authentication may take place through any appropriate technique. Forexample, a message-generating fuel dispenser may include an identifierand password in a message to a service-providing fuel dispenser. Theauthentication may take place on a message-by-message,transaction-by-transaction, or session-by-session basis.

In other implementations, fuel dispensers 1022 may not be arranged ingroups of islands 1020. Thus, the illustrated implementation has beenused in a non-limiting manner to describe coordination among a number offuel dispensers located in and around a retail fueling facility bycommunicating messages over a communication link to transport messagesamong the fuel dispensers.

In addition to transporting messages among fuel dispensers of differentislands 1020, communication link 1054 of this example implementation isalso coupled to a communication network 1050, which includes a networkhub 1052, and facility auxiliary equipment 1060. Network hub 1052 mayprovide message distribution services, for example, for messages sent inpackets or frames over communication link 1054. In alternativeimplementations, islands 1020 and/or fuel dispensers 1022 may bearranged in a hub-and-spoke structure around hub 1052, or they may bearranged in a ring, a hierarchical, or a daisy-chain networkconfiguration, for example. In some implementations, for instance, amessage may have to traverse one or more intermediate fuel dispensers toreach its destination. Communication link 1054 also transports messages,such as commands, data, or control signals, between hub 1052 or theislands 1020 and facility auxiliary equipment 1060.

Facility auxiliary equipment 1060 generally provides functionality thatis not specific to a particular island 1020 but supports functionalityfor retail fueling facility 1010. Facility auxiliary equipment 1060 maybe controlled by commands, such as commands generated by one of the fueldispensers 1022. Examples of facility auxiliary equipment 1060 includecommunication equipment (e.g., intercom), audio and/or video recordingor playback systems, diagnostic equipment, such as fuel spill detectors,emergency fuel shut-off controls, theft deterrent systems, surveillanceequipment, lighting, and proximity detection equipment to detect thepresence and/or location of vehicles near the island 1020, for example.

Network hub 1052 is also configured to distribute messages from afacility controller 1070. Facility controller 1070 may include acomputing system, such as a client connected to a remote server (notshown) through a communication link 1080 coupled to a communicationnetwork 1090 that is external to the retail fueling facility 1010. Insome implementations, communication link 1080 may transport packets ofinformation in digital format over wired, fiber optic cable, or wirelesschannels, including, for example, UTP, phone line, T-1, ISDN, and thelike. Network 1090 may be implemented in a network system such as, forexample, a VPN (virtual private network), WAN (wide area network), WLAN(wireless local area network), IEEE 802.16 Wireless MAN (wirelessmetropolitan area network), or the Internet. In other implementations,facility controller 1070 may include a stand-alone computing system,such as a PLC (programmable logic controller), laptop, desktop, orhandheld computer that may or may not be connected to an externalnetwork, such as network 1090. In other implementations, fuel dispensers1022 may communicate with a computer remote from system 1000 throughfacility controller 1070 or through another route, perhaps bycommunicating with a communication network outside of facility 1010.

Via network hub 1052, facility controller 1070 may send messages relatedto coordinated operation to one or more of fuel dispensers 1022. Themessages may include program instructions or information such as controlsignals or data. The program instructions may, for example, be stored insome or all of the fuel dispensers 1022 to configure the fuel dispensersto operate in a coordinated manner. Some implementations may provide forthe fuel dispensers to execute the program instructions and performcoordinated operation without, or substantially without, additionalinformation from the facility controller. Facility controller 1070 mayalso receive messages from fuel dispensers 1022 via hub 1052. Messagesfrom the fuel dispensers may include, for example, status data, requestsfor maintenance, and data, such as quantities of fuel dispensed andrecorded transaction information. The messages may further include datafrom auxiliary equipment 1026 or 1060, such as image and/or audioinformation. Some data may be passed between facility controller 1070and fuel dispensers 1022 when the fuel dispensers are operating inservice (i.e., on-line) or not in service (i.e., off-line). When thefuel dispensers are on-line, some data (e.g., data related to safety ortheft) may be exchanged with the facility controller 1070 in real-time,while other data (e.g., updated program instructions, diagnosticresults, etc.) may be exchanged at intervals.

Although an exemplary retail fueling facility 1010, which may sellretail gasoline and/or diesel fuels for general-purpose vehicles (e.g.,automobiles and/or trucks), has been described with reference to FIG.10, other implementations may be deployed in other fuel dispensingapplications, such as commercial, wholesale, or private fuel dispensinginstallations. Fuels that are dispensed may, for example, be forautomotive, aviation, and/or marine vehicles.

FIG. 11 illustrates one implementation of a network system 1100 for fueldispensers. Using network system 1100, fuel dispensers 1110 maycommunicate messages to coordinate their operations. As illustrated,network system 1100 includes three fuel dispensers 1110 that maycommunicate with each other to perform operations in a coordinatedmanner.

Each of fuel dispensers 1110 includes a controller 1112 that has anetwork interface 1113. Controllers 1112 are each coupled to a userinterface (UI) 1114, a fuel controller 1116, and auxiliary equipment1118. Aspects of an exemplary fuel dispenser will be described infurther detail below with reference to FIG. 12.

In this implementation, fuel dispensers 1110 may communicate with eachother over a communication link 1120 that is coupled to each fueldispenser's network interface 1113 (e.g., network interface card).Communication link 1120 may connect fuel dispensers 1110 in a network,such as a LAN. Also in this example, communication link 1120 is coupledto a hub 1130, which may provide message distribution services as wellas an interface to another communication link 1140. Hub 1130 maydistribute messages among fuel dispensers and/or between the fueldispensers 1110 and communication link 1140, which may convey messagesto a facility controller and/or other fuel dispensers.

In addition to, or instead of, communication link 1120, fuel dispensers1110 may communicate with each other over a communication link 1150. Inthis implementation, communication link 1150 is coupled to each fueldispenser 1110 via a communication interface (e.g., RS-232) associatedwith auxiliary equipment 1118. Communication link 1150 may include wiredand/or wireless links. Communication link 1150 may provide a channeldedicated to communicating information among fuel dispensers 1110, inthat it may not directly transport messages between network hub 1130 andfuel dispensers 1110.

In one illustrative example, controller 1112 in fuel dispenser 1110 bmay generate a service request message to be sent to the fuel dispensers1110 a, 1110 c via communication link 1120 and respective networkinterfaces 1113. The receiving fuel dispensers 1110 a, 1110 c mayrespond to the service request message by performing one or moreoperations. The receiving fuel dispensers 1110 a, 1110 c may simplylisten for the messages from fuel dispenser 1110 b, or they mayinteractively communicate with fuel dispenser 1110 b. If configured tolisten for the messages, the respective controllers 1112 may performoperations, for example, as computational bandwidth and resources becomeavailable (e.g., low priority interrupt), immediately upon receipt(e.g., non-maskable interrupt), at predetermined times of day, inresponse to predetermined inputs, or during regularly scheduled timesfor servicing such requests. If configured to interactively listen forand respond to the messages from fuel dispenser 1110 b, fuel dispensers1110 a, 1110 c may perform operations in a predetermined sequence, forexample, in which a fuel dispenser may wait to perform some operationsuntil it receives a message that indicates that a preceding operationhas been performed by another fuel dispenser.

FIG. 12 illustrates one implementation of a fuel dispenser 1200 for fueldispenser management. Fuel dispenser 1200 may be one example of fueldispensers 1110. The components of fuel dispenser 1200 may be involvedin the communication of network messages and/or performance of fueldispensing operations. Fuel dispenser 1200 includes a controller 1210that has a network interface 1224, a user interface (UI) 1230, a fuelcontroller 1240, and auxiliary equipment 1250. Controller 1210 may, forexample, be a special-purpose or general-purpose computer.

Controller 1210 provides the local intelligence for communications andoperation of the fuel dispenser 1200, including operations that may becoordinated with one or more other fuel dispensers. Controller 1210includes a processor 1212, such as a microprocessor, microcontroller,programmable logic device, or other appropriate device for manipulatinginformation in a logical manner. Processor 1212 is coupled to a bus 1226that enables processor 1212 to exchange information with peripheral orsupport devices, including an NVM (non-volatile memory) 1214, a RAM(random access memory) 1216, a DSP (digital signal processor) 1218, anHW (hardware) controller 1222, an I/O (input/output) controller 1220,and a network interface 1224. NVM 1214 provides non-volatile datastorage, and may include a computer program product containing storedinstructions that, when executed by the processor 1212, causes theprocessor to perform operations (as described in this document) in acoordinated manner with two or more other fuel dispensers. The computerprogram product may, for example, be a module that operates inassociation with a dispenser manager, which may be part of or in thecontroller 1210. The dispenser manager, for example, may be a computerprogram product that is also in NVM 1214 and/or a combination ofcomponents of controller 1210, (e.g., processor 1212, HW controller1222, I/O controller 1220, and/or network interface 1124). RAM 1216 mayprovide volatile data storage that the processor may use, for example,as a scratchpad. DSP 1218 may allow fuel dispenser 1110 to performcomputationally intensive operations in a coordinated manner, such asvideo or audio recognition or synthesis.

In one example, DSP 1218 may process a large data set including videoimage data, and may be used detect when a vehicle is proximate the fueldispenser 1200. If, for example, DSP 1218 determines that the vehiclehas moved away from the fuel dispenser, and processor 1212 determinesthat payment has not been received for fuel that has been dispensed,steps may be taken to record a potential drive-off situation. The fueldispenser that detects the potential drive-off situation may, forexample, send messages to other fuel dispensers with control overimaging equipment to try to capture images of the event. The request mayspecify a time delay for a particular camera to record images at aparticular angle so as to increase the likelihood of capturingidentifying information about the driver and the vehicle, for instance.

User interface 1230 is coupled to controller 1210 through I/O controller1220. In this example, UI 1230 includes a display device 1232, an inputdevice with audio system 1234, and a card reader 1236, to read debit andcredit cards. UI 1230 may further include a printer (not shown) toprovide a transaction receipt to customers who wish to pay for thetransaction using, for example, a payment card.

Fuel controller 1240 is coupled to controller 1210 through HW controller1222. Fuel controller 1240 includes a meter 1242 and a pump 1244. Themeter measures, for example, the amount of fluid dispensed, which thecontroller 1210 may use to determine the amount of fuel dispensed in aparticular transaction, for instance. Fuel pump 1244 pumps fuel to bedispensed from a fluid conduit.

Auxiliary equipment 1250 is also coupled to controller 1210. In thisimplementation, auxiliary equipment 1250 includes a communication (COM)port 1252, which may use, for example, a serial port. COM port 1252 maycouple to a serial bus, such as the communication link 1150 in FIG. 11.Auxiliary equipment 1250 also includes an imaging system 1254 and a setof sensors 1256. Imaging system 1254 may control one or more camerasassociated with the fuel dispenser, and these may be used in acoordinated manner to detect and identify a potential drive-off, as hasbeen described above. Imaging system 1254 may capture still or motionimages. Sensors 1256 include a tamper sensor 1258, a vehicle proximitysensor 1260, and diagnostic equipment 1262.

Imaging system 1254 may also be used to capture data before a drive-offevent occurs. For example, depending on conditions (e.g., after 10:00 pmand/or no pre-dispensing customer identification), the imaging systemmay image a customer and/or vehicle during a fueling session. With theuse of motion determining equipment, (e.g., DSP 1218), it may also bepossible to begin imaging before a fueling session begins, which mayincrease the chance of capturing identifying data (e.g., the vehicle'slicense plate). If the customer later pays for the dispensed fuel, thefuel dispenser may erase the image(s) from its memory. If, however, thecustomer does not pay for the fuel within a predefined period of time(e.g., ten minutes), the fuel dispenser may convey to images to a remotecomputer to generate a report for the authorities or generate the reportitself.

The fuel dispenser may also coordinate with other fuel dispensers tocapture image data before, during, or after the fueling session. Thisimage data may increase the likelihood of capturing identifying data.This image data may be sent to the requesting fuel dispenser where itmay be stored and later erased or conveyed. The data may also betemporarily stored at the imaging dispenser(s) until the fuel dispenserin use decides whether or not the image data is useful. The fueldispenser in use may then inform the assisting fuel dispenser(s) as towhether to erase or convey the image data.

Imaging system 1254 may also capture images of physical conditionsaround the fuel dispenser. For example, images regarding the ground maybe useful for determining whether a fuel leak is occurring, and imagesof the fuel dispenser itself may be useful for determining whether thefuel dispenser has been improperly accessed (e.g., open access panel).Imaging of the physical conditions around the fuel dispenser may also beaccomplished with imaging systems of other fuel dispenser to provideadditional image data of the fuel dispenser and its environment. Thefuel dispenser may coordinate this imaging. The image data may be storedlocally at the fuel dispenser and/or sent to a remote site, such as, forexample, a service provider's computer.

Imaging system 1254 may additionally be used for providingcustomer-service. For example, the imaging system may image the area inthe vicinity of the fuel dispenser so that a store attendant or otherperson knowledgeable with the functioning of the fuel dispenser mayassist a customer.

Diagnostic sensors 1262 may also be used in a coordinated manner. Forexample, if a fuel dispenser detects a problem with itself or itsenvironment, it may contact other fuel dispensers to determine if theyare detecting similar problems. If, for instance, only the initiatingfuel dispenser is experiencing a problem, it may take appropriatemeasures to alleviate the problem (e.g., restarting, redistributing oneor more of its operations, or shutting down). If all the fuel dispensersare experiencing the same problem, however, they may all need to resetand/or shut down.

FIG. 13 illustrates a process 1300 for managing a fuel dispenser.Process 1300 generally illustrates a process for coordinating operationsbetween fuel dispensers and may illustrate the operations of one or moreof the above-described fuel dispensers. In particular, the process maybe implemented by a management module for a fuel dispenser.

Process 1300 begins with a fuel dispenser (FD #1) identifying at leastone operation to be performed (operation 1305). The operation(s) may beidentified, for example, in response to the occurrence of a condition,such as the presence of an input signal (i.e., a user command), a sensorinput (e.g., detection of a potential drive-off), or receipt of amessage from another fuel dispenser (i.e., the message contains arequest that FD #1 perform the operation(s)). FD #1 then evaluateswhether the identified operation(s) involve coordination with at leastone other fuel dispenser (operation 1310). If it does not, FD #1performs the identified operation(s) (operation 1315), and the processends (operation 1320). However, if the identified operation does involvesuch coordination, FD #1 identifies which fuel dispensers are to performthe coordinated operations (operation 1325).

Next, the process bifurcates into two parallel paths. On one path, FD #1performs any identified operations at appropriate times that arecoordinated with the operations being performed by the other fueldispensers (operation 1330). In some examples, FD #1 may not have anyoperations to perform, in which case this portion of the process is atan end (operation 1320).

On the other path, FD #1 evaluates whether a message containing thecoordination request will be broadcast to all other fuel dispensers(operation 1335). A message may be broadcast, for example, if theidentified operation is to be performed by all available fueldispensers. If a message will be broadcast, FD #1 assembles a networkmessage containing the identified operation (operation 1340) and sendsthe network message to all active fuel dispenser network addresses(operation 1345). If the message will not be broadcast, FD #1 selects afirst one of the identified fuel dispensers (operation 1350), determinesthe operation to be performed by the selected FD (operation 1355), anddetermines the instruction(s) to be performed by the selected fueldispenser (operation 1360). The determined instructions may include oneor more commands that prompt the selected fuel dispenser to perform thedetermined operations when the instructions are received. Theinstructions may also include data for the selected fuel dispenser touse in performing the operation. FD #1 then identifies a network addressof the selected FD (operation 1365) and assembles a network messagecontaining the identified network address and the determinedinstruction(s) (operation 1370). FD #1 sends the assembled networkmessage over the network (operation 1375). If the determined operationsfor the selected fuel dispenser have a long length or include multiplecommands, more than one network message may be sent. In coordinationwith operations performed by the selected fuel dispenser, FD #1 maycontinue to perform operations, if any, at appropriate times (operation1330).

After sending the network message, FD #1 determines whether anyidentified fuel dispensers have not yet been sent a network message(operation 1380). If there are more identified fuel dispensers, FD #1selects another fuel dispenser (operation 1385), and the process offorming and sending a message for the fuel dispenser (operations1355-1375) begins again. However, if no other fuel dispensers have beenidentified, the process ends (operation 1320).

The exemplary process of FIG. 13 involves identifying fuel dispensers toperform coordinated operations. Fuel dispenser #1, which is themessage-generating fuel dispenser, may identify fuel dispensers usingvarious techniques. For example, the operation to be performed may belinked to a set of fuel dispensers that have been identified as the fueldispensers to perform coordinated operations. Such a link may be definedin a database, in a table, or in a list. In some implementations, theset of fuel dispensers identified may be static, such as informationthat is downloaded at system configuration time. In otherimplementations, the set of fuel dispensers associated with anidentified operation may be dynamically determined. For example, the setof fuel dispensers identified may be calculated based on currentconditions of fuel dispensers. In some circumstances, some fueldispensers may have sufficient unused bandwidth to efficiently handleadditional computational tasks and/or message traffic that may berequired to perform the operations within the required time frame. Fueldispensers that are currently idle, for example, may generally be morelikely to be identified, presuming they are otherwise suitable toperform the coordinated operations. However, an idle fuel dispenser withan out-of-service video camera, for example, would not be eligible to beidentified to perform an image capture operation of a possible drive-offevent. Optimization algorithms, using techniques such as least-squarederror and/or regression processes, may be developed for specificimplementations to optimize the identification of fuel dispensers toperform coordinated operations.

Although one implementation of a process for fuel dispenser managementhas been described, other implementations may perform the operations ina different sequence or a modified arrangement to achieve the sameprimary function, which is to coordinate operations performed by two ormore fuel dispensers.

In various implementations, fuel dispensers may communicate usingsuitable communication methods, equipment, and techniques. For example,the fuel dispensers 1022 (FIG. 10) may communicate from a source fueldispenser to a destination fuel dispenser using point-to-pointcommunication in which a message is transported directly from the sourceto the receiver over a dedicated physical link (e.g., fiber optic link,point-to-point wiring, daisy-chain). Other implementations may transportmessages by broadcasting to all or substantially all fuel dispensersthat are coupled together by a communication network, for example, byusing omni-directional radio frequency (RF) signals, while still otherimplementations may transport messages characterized by highdirectivity, such as RF signals transmitted using directional (i.e.,narrow beam) antennas or infrared signals that may optionally be usedwith focusing optics. Still other implementations are possible usingappropriate interfaces and protocols such as, by way of example and notintended to be limiting, RS-232, RS-422, RS-485, 802.11 a/b/g, Wi-Fi,Ethernet, IrDA, FDDI (fiber distributed data interface), token-ringnetworks, or multiplexing techniques based on frequency, time or codedivision. Some implementations may optionally incorporate features suchas error checking and correction (ECC) for data integrity, or securitymeasures, such as encryption (e.g., WEP) and password protection.

In some implementations, each fuel dispenser may be programmed with thesame data and be initialized with substantially identical data stored innon-volatile memory. In other implementations, one or more fueldispensers in an installation may be custom configured to performspecific functions. For example, one fuel dispenser may be configured toperform routing functions by routing messages among fuel dispensers inan island or between fuel dispensers in different islands.

To establish communication, individual fuel dispensers may identifythemselves over the network by sending a unique identifier. In otherimplementations, for example, a router, switch, or bridge may handle theflow of message traffic to enable messages to be routed to a specificdestination fuel dispenser based on a network address, for example.Network messages may, for example, be structured in packets that includea header to identify a network address of a destination fuel dispenserand/or to identify the destination device as a particular type of fueldispenser.

In addition, some implementations may permit communication in abroadcast mode, in which a message-generating fuel dispenser may sendmessages to be received by all other fuel dispensers in the same retailfueling facility or coupled to the same communication link or network.Various network arbitration methods, such as passing a token, forexample, may be used to handle or avoid collisions when more than onefuel dispenser attempts to send a message at the same time.

Configuring fuel dispensers with the ability to coordinate theiroperations may provide one or more beneficial features. For example,allowing coordination between fuel dispensers may permit operations tocontinue in the absence or interruption of communications between a fueldispenser and a central controller. Accordingly, fuel dispensingoperations and other transactions at the fuel dispenser may continueduring interruptions in the communication link to the centralcontroller, such as during periods of maintenance, re-boots, or lowbandwidth of the central controller, for example. In addition,coordination among fuel dispensers may provide expanded functionality,such as coordination among multiple fuel dispensers to operate camerasto capture images of non-paying customers (i.e., drive-offs) frommultiple vantage points. Furthermore, customer service may also beenhanced by providing redundant equipment in the event of equipmentproblems. For example, if a receipt cannot be printed at one fueldispenser station due to lack of paper, a receipt may be printed at anearby fuel dispenser that is available. Still further, fuel dispensercoordination may provide for improved diagnostic capabilities to detectand accurately identify fuel dispenser problems at an early stage.Accordingly, fuel dispenser coordination may promote increased revenueand reduced losses, for example, by improving the availability (i.e.,uptime) of fuel dispenser functions, expanding functional capabilities,promoting safety, and improving customer experiences.

FIG. 14 illustrates one example of a process 1400 for managing a fueldispenser. Process 1400 generally relates to providing diagnosticservices at a fuel dispenser. Process 1400 may, for example, beimplemented by one or more of the above-described fuel dispensers.

Process 1400 begins with determining whether a condition has beendetected at the fuel dispenser (operation 1404). Determining whether acondition has been detected at the fuel dispenser may, for example, beaccomplished by determining whether one or more sensors have made areading or one or more processors have made a condition determination.Conditions that could be detected include environmental, mechanical,electrical, and/or logical instruction conditions, such as, for example,temperature, pressure, humidity, fuel leaks, open panels, dispenserintrusion, power irregularities, watchdog timer expiration, or softwareexceptions. Condition determinations may be made on time-driven orevent-driven basis.

If a condition has not been detected, process 1400 calls for determiningwhether revised diagnostic instructions are available (operation 1406).Determining whether revised diagnostic instructions are available may,for example, be accomplished by determining whether a message indicatingthat revised diagnostic instructions are available has been received orby generating a message inquiring whether revised diagnosticinstructions are available. The instructions may, for example, beavailable from a remote server. If revised diagnostic instructions areavailable, process 1400 calls for downloading the revised diagnosticinstructions (operation 1408). The fuel dispenser may, for example,enter into a client-server relationship to download the instructions.Once the revised instructions have been downloaded, process 1400 callsfor again determining whether a condition has been detected at the fueldispenser (operation 1404).

If, however, there are no revised instructions available, process 1400calls determining whether a diagnostic request has been received(operation 1410). A diagnostic request may, for example, request dataregarding or specify a diagnostic command for a fuel dispenser component(e.g., a dispenser manager, a fuel controller, or other appropriate fueldispenser component). A diagnostic command may, for example, specify asoft reset, revised operational instructions (e.g., software), or anyother appropriate command affecting the operation of the pump component.An interrogation command may, for example, include an identifierrequest, a status request, or any other appropriate request regardinginformation about a fuel dispenser component. A diagnostic request maybe received from a fueling facility computer remote from the fueldispenser (e.g., a facility controller) or any other appropriate device.

If a diagnostic request has been received, process 1400 calls forimplementing the diagnostic request (operation 1412). Implementing adiagnostic interrogation request could, for example, include retrievingstatus data from a fuel dispenser component and providing the data tothe requesting device. Implementing a diagnostic command request could,for example, include issuing a command to a fuel dispenser component.Once the diagnostic request has been implemented, or if no diagnosticrequest has been received, process 1400 calls for again determiningwhether a condition has been detected at the fuel dispenser (operation1404).

If a condition has been detected at the fuel dispenser, process 1400calls for determining whether the condition warrants a response(operation 1416). Whether a condition warrants a response may depend onwhether the condition exists, the degree of the condition, and/or one ormore other conditions. For example, the existence of some conditions(e.g., open panel, improper access, or fuel leak) may warrant aresponse. As another example, some conditions (e.g., temperature orjitter pulses) may have an acceptable range (e.g., 0-140.degree. F. orjitter pulse less than once a week, respectively) in which the conditiondoes not warrant a response. Whether a condition warrants a response maybe expressed as one or more logical conditions in a set of logicalinstructions. If the condition does not warrant a response, process 1400calls for determining whether another condition has been detected at thefuel dispenser (operation 1404). Data regarding the detected conditionmay be discarded or saved for later analysis or reporting.

If, however, a condition does warrant a response, process 1400 calls fordetermining whether the fuel dispenser should be restarted (operation1420). The fuel dispenser may need to be restarted, for example, ifpower irregularities have been detected, if software exceptions occur,if watchdog timers expire, if communication within the dispenser fails,or if communication with the facility controller fails. An example ofthe last includes determining that a card reader is not receiving apolling message. Another example of the last includes determining whenthe fuel dispenser is not in an idle mode and it is trapped (e.g.,waiting for a pre-authorization response). If the fuel dispenser needsto be restarted, process 1400 continues with restarting the fueldispenser (operation 1424), which may include resetting certaincomponents (e.g., rebooting processor-based components or resetting acommunication line to the facility controller), powering down certaincomponents, or powering down the entire fuel dispenser. Once the fueldispenser has been restarted (a process that may take betweenapproximately a few seconds to a couple minutes), process 1400 calls fordetermining whether another condition has been detected at the fueldispenser (operation 1404).

If the fuel dispenser does not need to be restarted, process 1400 callsfor determining whether the fuel dispenser should be shut down(operation 1428). The fuel dispenser may need to be shut down, forexample, if a fuel leak, an electrical short, a fire, liquid (e.g.,water) in the pan, improper vapor recovery, or unauthorized access isdetected. The conditions may be detected by any appropriate sensors. Ifthe fuel dispenser need to be shut down, process 1400 continues withshutting down the fuel dispenser (operation 1432). Shutting down thefuel dispenser may include placing mechanical components into safepositions, shutting down processor-based components, and removing powerfrom electrical components. Once the fuel dispenser has been shut down,process 1400 is at an end.

If, however, the fuel dispenser does not need to be shut down, process1400 calls for determining whether the fuel dispenser should downloadinstructions (operation 1436). The fuel dispenser may need to downloadinstructions if, for example, repeated error conditions occur (e.g., oneor more watchdog timers continues to expire, one or more softwareexceptions continues to occur, a customer card read continues to fail,or the fuel dispenser has restarted itself a certain number of times ina given time period (e.g., three restarts in a three hour period)). Thefuel dispenser may also need to download instructions if it detects thatit is not operating in an efficient manner. For example, the fueldispenser may monitor the flow rate of fuel. If the flow rate deviatesfrom a designated range (e.g., between eight to ten gallons per minute),the fuel dispenser may adjust the valves to adjust the flow rate.Adjusting the valves may call for downloading appropriate instructions.Other operations of the fuel dispenser may be similarly adjusted.

If instructions need to be downloaded, process 1400 continues withdetermining whether there are appropriate instructions to download(operation 1440). Determining whether there are appropriate instructionsto download may, for example, include generating an inquiry for orpolling a remote computer (e.g., server). If there are appropriateinstructions to download, process 1400 calls for downloading theinstructions (operation 1444). The instructions may be in the form of arule set, a portion of a rule set, a software application, a patch, orany other appropriate set of logical instructions. The instructions maybe in the form of software or firmware updates. Once the instructionshave been downloaded, or if there are no appropriate instructions todownload, process 1400 calls for determining whether another conditionhas been detected at the fuel dispenser (operation 1404).

If, however, the fuel dispenser does not need to download instructions,process 1400 calls for determining whether a notification is required(operation 1448). A notification may, for example, be required if afacility controller, other fuel dispensers at the fueling facility, orother components, whether at the fueling facility or not, need to benotified of the condition. For example, if a leak in a trunk line (atype of fluid conduit) is detected, all of the fuel dispensers at thefueling facility may need to be notified that they need to shut down. Asanother example, if a parameter is out of tolerance (e.g., power level,flow rate, number of transactions per hour, or sales amounts) a remoteand/or fueling facility device or person may need to be notified. If anotification is required, process 1400 continues with generating thenotification (operation 1452). The notification may, for example, be amessage directed to one or more other components at the fuelingfacility. Additionally, the message may be directed to a computer remotefrom the fueling facility. For example, a message (e.g., e-mail, SMS, orinstant message) may be sent to a service provider and/or fuel dispensermanufacturer where it may be analyzed by a person or computer (e.g., PC,server, workstation, or PDA). The analysis may include conditionanalysis, diagnosis, and trending analysis. The message may or may notbe sent through another fueling facility component. Once thenotification has been generated, or if there is no notificationrequired, process 1400 calls for determining whether another conditionhas been detected at the fuel dispenser (operation 1404).

The diagnostic services illustrated by process 1400 possess severalfeatures. For example, by being able to shut down only one fueldispenser, a fueling facility may be able to continue operating when aproblem that is localized to one fuel dispenser is detected. As anotherexample, by being able to attempt to fix itself, a fuel dispenser may beable to resume operation without having to be serviced, which mayincrease its ability to dispense fuel. As a further example, by beingable to process diagnostic interrogation and command requests, a fueldispenser may be able to provide relevant diagnostic data regarding itsoperations and/or be controlled for diagnostic purposes. This mayprovide insight into the status of a fuel dispenser that ismalfunctioning and provide techniques for correcting the problem(s).

The diagnostic service operations of process 1400 may be accomplished byany of a variety of hardware and/or software combinations. For example,the operations may be performed by a management module associated with adispenser manager, as illustrated in FIG. 2, for example. In suchimplementations, the diagnostic operations may be expressed asinstructions, and the diagnostic data may be stored in logs, especiallyif an attempted correction does not fix a condition. Such a managementmodule may exclusively provide diagnostic services, with or withoutother management modules providing other services, or provide otherservices too (e.g., POS, fuel dispenser coordination, and/or datasecurity).

In certain implementations, a fueling facility may include a gateway(e.g., a server) to provide a variety of services based on fueldispenser diagnostics. For example, the gateway may provide localreporting, alerting, and routing. Alerts may, for example, be sentto: 1) a service center for reporting, alerting, or routing of serviceproviders; and 2) a fuel dispenser manufacturer for reporting oralerting. As part of its operations, the gateway may discard data fromfuel dispensers because it is irrelevant, forward data to othercomponents for processing or storage, store data in a local database forlater reporting or analysis, and generate alerts for mobile devices forreaction. The gateway may also act as an application and configuration(e.g., plug and play) server for fuel dispensers. The gateway may or maynot be part of the facility controller.

A diagnostics manager may include the ability to issue diagnosticoperation commands and/or interrogation commands to one or more fueldispenser components. The diagnostics manager may, for example, be asoftware component that resides on the dispenser and/or on a remotefueling facility computer (e.g., a facility controller or a gateway).For communications to a fuel dispenser, a diagnostics manager may, forexample, issue XML messages over TCP/IP. The fuel dispenser components(e.g., dispenser manager and management module) may also communicateusing XML messages. Other appropriate messaging techniques, whetherstatic, dynamic, or otherwise, and communication protocol schemes,whether local, regional, or global, may also be used. One or more of afuel dispenser's components may have to be modified to have the abilityto accept diagnostic operation commands and/or interrogation commands.For example, a component may have to be modified to respond to adiagnostic interrogation (e.g., for identifiers or status) and to adiagnostic command (e.g., to implement a soft reset or revisedoperational instructions). Modifications may include the ability toreceive, recognize, and respond to the diagnostic requests.

Although FIG. 14 illustrates one example of a process for fuel dispensermanagement in which the fuel dispenser provides diagnostic services,other processes for fuel dispenser management in which the fueldispenser provides diagnostic services may include fewer, additional,and/or a different arrangement of operations. For example, checking forrevised diagnostic instructions may occur on a periodic basis (e.g.,once a day). As another example, when a condition warrants a response, aprocess may implement a response without determining whether theresponse should be implemented. As another example, more than oneresponse may be implemented in response to a condition. For instance, ifthe fuel dispenser detects an internal fuel leak, the fuel dispenser mayshut itself down and notify other fuel dispensers that it is shuttingdown, or if a fuel dispenser detects a leak in a trunk line, the fueldispenser may shut itself down and notify other fuel dispensers thatthey also should shut down. By being able to notify other fuelingfacility components of local conditions, a fuel dispenser may be able toincrease the safety of the entire fueling facility. As a furtherexample, one or more of the responses (e.g., restarting the fueldispenser or shutting down the fuel dispenser) may not be implemented.As an additional example, a response may be based on previous response.For instance, if a given number of restarts have already occurred in aperiod of time (e.g., three in one day), the next time a condition thatdictates a restart is detected, the fuel dispenser may try to downloadinstructions before restarting again. Also, if the new instructions donot alleviate the excessive restart sequence, the fuel dispenser mayrevert back to its previous configuration. Additionally, if resetting acommunication line does not resolve a problem, the communication boardfor the line may then be reset. As an additional example, a process maycall for one or more operations to be performed contemporaneously (e.g.,in an interleaved manner) or simultaneously (e.g., in a parallelmanner).

In particular implementations, a fuel dispenser may be able to initiatea coordinated operation with another fuel dispenser as, or as part of, aresponse. The ability for fuel dispensers to coordinate operations wasdiscussed above with respect to process 1300. For example, if a firstfuel dispenser detects a fluid (e.g., gas) leak, it may request anotherfuel dispenser to take an image of the first fuel dispenser. The imagemay be stored by one of the fuel dispensers or sent to a remote devicefor storage. The first fuel dispenser may also request the recording ofstatus data regarding the other fuel dispensers. Thus, if a servicetechnician must become involved, she may have more information regardingthe conditions at the fuel dispenser. Coordinated operations may also beused in conjunction with other responses. For example, a fuel dispenserthat detects a fluid leak may request imaging and/or status data fromanother fuel dispenser and then shut itself down.

FIG. 15 illustrates another implementation of a process 1500 formanaging a fuel dispenser. Process 1500 generally relates to providingdata security at a fuel dispenser of a fueling facility. Process 1500may be one example of a process performed at a fuel dispenser of fuelingfacility system 100.

Process 1500 begins with waiting for a fueling session to be initiatedat a fuel dispenser (operation 1504). Determining whether a fuelingsession has been initiated at a fuel dispenser may, for example, beaccomplished be detecting the presence of a customer identifier (e.g.,insertion of an electromagnetic payment card (e.g., a credit card) orpresence of a wireless payment authorizer (e.g., an RFID tag)), userinteraction with a fuel dispenser input device (e.g., a keypad), theremoval of a fuel dispenser pump handle, or any other appropriateindicator of customer interaction with a fuel dispenser.

Once a fueling session has been initiated at a fuel dispenser, process1500 calls for waiting for a portion of transaction data for the fuelingsession to be received at the fuel dispenser (operation 1508). Thetransaction data portion may, for example, include a customer's accountnumber, identification code, authorization code (e.g., PIN number),and/or purchase information. The data portion may be acquired at thebeginning, middle, or end of a fueling session.

Once a portion of transaction data has been received, process 1500 callsfor determining whether the data portion is to be stored at the fueldispenser (operation 1512). A data portion may, for example, be storedat the fuel dispenser if it needs to be held for a certain time or eventbefore being sent to a remote device or if a communication link is notavailable. In some implementations, a data portion may be stored at thefuel dispenser for a transitory period of time (e.g., a few nanosecondsto a few seconds) without it being considered as being stored at thefuel dispenser.

If the data portion is to be stored at the fuel dispenser, process 1500calls for determining whether the data portion requires a securitymeasure (operation 1516). A data portion may, for example, require asecurity measure if its type has been designated as a sensitive piece ofinformation (e.g., a customer account number). If the data portionrequires a security measure, process 1500 continues with encrypting thedata portion (operation 1520). The encryption may be accomplished by anyappropriate scheme (e.g., a public key or a private key scheme). Oncethe data portion has been encrypted, or if the data portion does notrequire a security measure, process 1500 calls for storing the dataportion at the fuel dispenser (operation 1524). The data portion may,for example, be stored in a transaction log with other transaction dataor in a separate portion of memory.

Once the data portion has been stored, process 1500 calls fordetermining whether the fueling session is finished (operation 1528). Ifthe fueling session is finished, the process is at an end. A fuelingsession may be finished, for example, if a customer has stopped pumpingfuel and completed the purchase of it. If, however, the fueling sessionis not finished, process 1500 calls for determining whether anotherportion of transaction data has been received at the fuel dispenser(operation 1508). The stored data portion may eventually be conveyed toa remote facility computer (e.g., a facility computer). The data portionmay be conveyed in an encrypted or unencrypted format.

With reference again to operation 1512, if it is determined that a dataportion is not to be stored at the fuel dispenser, process 1500 callsfor determining whether the data portion is to be conveyed to a fuelingfacility computer (operation 1532). Data may, for example, need to beconveyed to a fueling facility computer if the data assists incompleting a fueling session transaction (e.g., payment card data) or inmonitoring the status of the fuel dispenser. Conveyance to a fuelingfacility computer may, for example, be a prefatory operation toconveyance to a computer remote from the fueling facility. The fuelingfacility computer may, for example, be a personal computer, aworkstation, a server, or a router. If the data portion is not to beconveyed to a fueling facility computer, process 1500 calls fordetermining whether the fueling session is finished (operation 1528).

If, however, the data portion is to be conveyed to a fueling facilitycomputer, process 1500 calls for determining whether the data portionrequires a security measure (operation 1536). A data portion may, forexample, require a security measure if its type has been designated as asensitive piece of information (e.g., a customer account number). If thedata portion requires a security measure, process 1500 calls forpreparing the data portion for conveyance over a wireline link(operation 1540). Preparing the data portion for conveyance over awireline link may, for example, include designating the data portion forcommunication over the wireline link, scheduling the data portion forcommunication over the wireline link, formatting the data portion in acommunication protocol for the wireline link (e.g., by encapsulation orencoding), and/or sending the data portion over the wireline link. Butif the data portion does not require a security measure, process 1500calls for preparing the data portion for conveyance over a wireless link(operation 1544). Preparing the data portion for conveyance over awireless link may be similar to preparing it for conveyance over awireline link. After preparing the data portion for conveyance, process1500 calls for determining whether the fueling session is finished(operation 1528).

Although FIG. 15 illustrates one implementation of a process formanaging a fuel dispenser to provide fueling facility data security,other processes for managing a fuel dispenser to provide fuelingfacility data security may include fewer, additional, and/or a differentarrangement of operations. For example, a process may not includedetermining whether a data portion to be stored at a fuel dispenserrequires a security measure. As another example, a process may includeconveying a data portion stored at the fuel dispenser to a fuelingfacility computer. Furthermore, before sending a stored data portion, adetermination may be made as to whether the data portion requires asecurity measure and implementing the security measure if it isrequired. As a further example, a process may include encrypting a dataportion before sending it over the wireline link or wireless link.Encryption may, for instance, be an additional or alternative securitymeasure when data is sent over a wireline or wireless link. Theencrypted data may be destined for the remote facility computer or acomputer outside of the remote facility (e.g., remote merchant computeror automated clearing house). As an additional example, a process maynot call for determining whether a data portion to be conveyed to afueling facility computer requires a security measure. As anotherexample, a process may call for determining whether a data portion is tobe conveyed to a fueling facility computer before determining whetherthe data portion is to be stored at a fuel dispenser. As a furtherexample, a process may call for determining whether a data portionrequires a security measure before determining whether a data portion isto be conveyed to a fueling facility computer or before determiningwhether a data portion to be stored at a fuel dispenser. As anadditional example, a process may call for one or more operations to beperformed contemporaneously (e.g., in an interleaved manner) orsimultaneously (e.g., in a parallel manner).

The data security operations of process 1500 may be accomplished by anyof a variety of hardware and/or software combinations. For example, theoperations may be performed by a management module associated with adispenser manager, as illustrated in FIG. 2, for example. In suchimplementations, the operations may be expressed as instructions, andthe transaction data may be stored in logs. Such a management module mayexclusively provide data security, with or without other managementmodules providing other services, or provide other services too (e.g.,POS, fuel dispenser coordination, and/or dispenser diagnostics).

FIG. 16 illustrates one implementation of a system 1600 for fueldispenser commerce. In general, system 1600 allows a fuel dispenser at aretail fueling facility 1610 to market and sell the goods and/orservices of remote merchants 1620.

Retail fueling facility 1610 includes fuel dispensers 1612, acommunication network 1614, and a network interface 1616. Fueldispensers 1612 may, for example, be similar to fuel dispenser 200 inFIG. 2. Communication network 1614 is coupled to fuel dispensers 1612and allows the fuel dispensers to communicate with network interface1616, which is also coupled to communication network 1614. Networkinterface 1616 may be any appropriate device for allowing communicationbetween the devices at retail fueling facility 1610 and remote devices,such as computers at remote merchants 1620. For example, networkinterface 1616 may be a gateway, a wide-area network router, or afacility controller.

To allow communication between fuel dispensers 1612 and remote merchants1620, system 1600 also includes a communication network 1630.Communication network 1630 may be any appropriate system for allowinginformation exchange, such as, for example, the Internet, a WAN, or aPSTN.

Remote merchants 1620 may be any appropriate sellers of goods and/orservices. For example, a merchant may sell durable goods (e.g., carparts or toys), perishable goods (e.g., food), intangible goods (e.g.,software or digital media), or services (e.g., oil changes). Remotemerchants 1620 may include any appropriate computer systems (e.g.,servers and databases) for allowing them to send data regarding theirgoods and/or services over communication network 1630 to fuel dispensers1612. Remote merchants 1620 may operate proactively, interactively,and/or or passively with fuel dispensers 1612 to market and/or selltheir goods and/or services. For example, the remote merchants maydownload merchandising content (advertisements and pricing data) to thefuel dispensers at designated times or events, or the remote merchantsmay download merchandising content to the fuel dispensers upon request.In certain implementations, the remote merchants may maintain a Webportal through which the fuel dispensers may download the content. Itshould be noted that remote merchants 1620 are remote in the sense thatthey are not located at retail fueling facility 1610. Thus, the remotemerchants may be located in the neighborhood of the retail fuelingfacility. One or more the merchants, of course, could be located atgreat distances (e.g., across the state or country) from the retailfueling facility.

In one mode of operation, remote merchants 1620 download data regardingtheir goods and/or services to fuel dispensers 1612 before the data isrequired at the fuel dispensers. The data may be downloaded at certaintimes (e.g., at night), upon certain events occurring (e.g., upon newdata being available), or upon request from the fuel dispensers (e.g.,if data is corrupted). The downloaded data may include a listing ofgoods and/or services, along with descriptions and pricing information.The downloaded data could also include text, graphics, audio, and/orvideo for presentation at the fuel dispenser. The data may be in anyappropriate format. Open-standard formats (e.g., ASCII for text, JPEGfor bitmaps, GIF or Macromedia for animations, or MPEG or AVI for video)may be especially useful. The downloaded data could be stored as contentat the fuel dispensers.

Fuel dispensers 1612 may then determine when to present the merchantdata. For example, a fuel dispenser may present the data at certainpoints of a fueling session (e.g., while fuel is being dispensed orafter fuel dispensing is complete). The fuel dispenser may thendetermine whether the customer indicates interest in the merchant data(e.g., by detecting user input regarding it). If the fuel dispenserdetects user interest in merchant data, the fuel dispenser may presentadditional information regarding the goods and/or services and determinewhether the customer desires to order a good and/or service. Additionalinformation regarding goods or services may include textualdescriptions, images, audio, and/or video.

If a customer desires to order a good and/or service, the fuel dispensermay acquire order data (e.g., quantity, price, and deliveryinformation). The fuel dispenser may also acquire payment data. Forinstance, the fuel dispenser may request the customer to present acustomer identifier (e.g., a payment card) and enter a PIN. The fueldispenser may then determine whether the payment data is acceptable. Forexample, the fuel dispenser may use business rules to determine whetherthe customer identifier is valid (e.g., by performing a checksum) andwhether the amount of the order is within predetermined a limit (e.g.,less than $50), which may be based on a customer profile. The fueldispenser may also evaluate whether the payment data is sufficientlycomplete. If the payment data is acceptable, the fuel dispenser may thengenerate a message for the appropriate one of remote merchants 1620regarding the order and payment information and generate a receipt forthe customer. The appropriate merchant may then make arrangement fordelivery of the good and/or service.

In another mode of operation, one or more of remote merchants 1620 couldprovide a portal (e.g., a Web portal) to interact with the fueldispensers. The portal may be responsible for providing data to the fueldispenser for presentation, obtaining order data, and/or obtainingpayment data. The data may be downloaded before it is required and/or asit is required. The fuel dispenser is, of course, also involved withpresenting the merchant data, obtaining the order data, and obtainingthe payment data. For example, the fuel dispenser actually presents theadvertising data, order data, and payment data. The fuel dispenser alsodetects order data (e.g., user selection of products and/or services)and payment data (e.g., user selection of payment type). Theseselections may be conveyed to the portal for handling and/or handledlocally. The fuel dispenser and the remote merchant portal may, forexample, communicate using standard Web portal calls over a TCP/IPnetwork.

One example of a service that could be ordered from a fuel dispenser isa pizza. A fuel dispenser customer could, for instance, order a pizzawhile fueling their vehicle. The customer could then pick the pizza upon the way to their destination (e.g., their house) or have the pizzadelivered to their destination (e.g., their work). Other examplesinclude ordering goods from catalog merchants (e.g., Lands' End or EddieBauer), Internet retailers (e.g., Amazon.com), or traditional retailers(e.g., Wal-mart, Target, or Barnes & Noble). Practically any businessthat has an on-line functionality may be able to take advantage of thissystem.

To facilitate customer interaction in particular implementations, a fueldispenser may be able to retrieve customer-related data. Thecustomer-related data could, for example, be associated with a customeridentifier (e.g., a credit card number, a personal identification number(PIN), a telephone number, a radio frequency identifier (RFID) number,or a loyalty program number). The customer identifier may allow for theready retrieval of the customer-related data. The customer-related datacould be information regarding a fueling session (e.g., a type of fuel,a display language for the fuel dispenser display, audio settings forthe fuel dispenser, or payment preferences (e.g., Exxon or Visa)), dataregarding services at the fueling facility (e.g., car wash, air pump, orwater hose), or data regarding the customer (e.g., address and preferredpayment types). In particular implementations, the customer-related datacould also be used to identify other information that may be of interestto the customer. For example, particular types of merchandise (e.g.,drinks, newspapers, or food) or offers (e.g., coupons or advertising)could be presented to the customer. This presentation could, forexample, be based on the customer's purchasing habits in a fuelingfacility store. The customer-related data may be acquired based oncustomer interaction with a fuel dispenser, or other components at afueling facility, or based on customer-specified criteria, entered atthe fuel dispenser, a local fueling facility computer, or a remotecomputer (e.g., through a Web interface). The customer-related data maybe stored locally at the fueling facility (e.g., at a facilitycontroller) and/or remotely (e.g., at a remote server). In certainimplementations, a hash function (e.g., MD5 or the Secure HashingAlgorithm (SHA)) could be applied the customer identifier beforeattempting to retrieve customer-related data. This could assist inkeeping the customer's identifier confidential.

In regard to commerce for remote merchants at a fuel dispenser, theability to retrieve customer-related data may provide many features. Forexample, a fuel dispenser may use retrieved customer data (e.g., buyingpreference or history) to determine what types of merchant data topresent to a customer. A fuel dispenser may, for instance, providecontent related to a particular merchant if a customer has indicated aninterest in a certain type of product (e.g., through predesignatedpreferences or buying history). The fuel dispenser may also be able toexpedite a transaction by being able to present payment options to thecustomer. For example, the customer-related data may contain informationregarding payment methods (e.g., credit cards, debit cards, etc.) that acustomer typically uses. If this information is available, the fueldispenser may be able to present the user (e.g., with text or graphicsymbols) with one or more choices (e.g., gas card, credit card, or debitcard) to use for paying for the goods and/or services. The user may thenselect the appropriate data by using a touch screen, stylus, keypad, orother appropriate device. A user would therefore not have to swipe, oreven have, the preferred customer identifier. The fuel dispenser could,of course, collect an identifier (e.g., PIN or password) if securitymeasures were required. As another example, the fuel dispenser may beable to facilitate delivery of products and/or services purchased from aremote merchant. The fuel dispenser may, for instance, be able topresent one or more addresses associated with the user (e.g., home oroffice) and/or inquire whether the customer desires to have a goodand/or service delivered to a particular address. The address selectionmay, for example, be made through the fuel dispenser presenting the userwith text or graphics symbols representing the address. The user maythen select the appropriate data by using a touch screen, stylus,keypad, or other appropriate device.

In particular implementations, the remote merchant data may be tied intoa digital merchandising framework. The framework may allow the retailerto control what content is presented on the fuel dispensers. Theretailer may, for example, choose among content from one or more remotemerchants and local content, which may be of the retailer's creation.The framework may, in fact, allow the retailer to create content for thefuel dispensers. For example, the framework may provide a Web site atwhich the retailer may log on to create content. The local contentcould, for example, offer products and/or services of the retailer(e.g., coffee, oil, car washes, etc.). The remote merchant data and theretailer created data may be stored at a gateway (e.g., a PC) at thefueling facility. The retailer may then select what content is to bedisplayed by the fuel dispensers. Selections may also be fine tuned fortime of day, temperature, etc. The selected content may be downloadedfrom the gateway to the fuel dispensers for presentation at appropriatetimes.

System 1600 has a variety of features. Customers, for example, are ableto use their downtime while fueling their cars to order goods and/orservices. This may be quite a convenience for busy customers. Moreover,the ordering and payment for goods and/or services may occur even ifsome of the fueling facility's components are temporarily unavailable.As another example, retail fueling facilities are provided with anotherrevenue stream, through, for example, advertising and sales-revenuesharing from the remote merchants. Moreover, providing thesecapabilities for a fuel dispenser may allow additional capabilities,some of which have been discussed previously, to be implemented.

Although system 1600 illustrates one implementation of a system for fueldispenser commerce, other systems for fuel dispenser commerce may havefewer, additional, and/or a different arrangement of components. Forexample, the fuel dispensers may not communicate with the remotemerchants though communication facilities of the retail fuelingfacility. The fuel dispensers may, for instance, have couplings to adistributed communication network (e.g., the Internet) or may be able tocommunication data wirelessly (e.g., by using GPRS or IEEE 802.11) to acommunication network, which could be a wireless network (e.g., acellular telephone network) or a wireline network (e.g., the Internet).Note that a wireless network or a wireline network may use a combinationof wireline and wireless techniques for conveying data internally. Inthese cases, retail fueling facility 1610 may or may not have a networkinterface. As another example, the retail fueling facility may includeadditional components, such as a store interface unit or a facilitycontroller. As a further example, the remote merchants may be located atvarious geographic locations (e.g., in the neighborhood of the retailfueling facility and/or across the country from the retail fuelingfacility).

Various implementations of systems for fuel dispenser commerce mayoperate in one or more modes. For example, a fuel dispenser may downloaddata regarding one or more goods or services as needed from the remotemerchant. This may be useful for alleviating memory constraints at thefuel dispensers. As another example, determining the validity of paymentdata may include soliciting assistance from outside sources (e.g., aremote merchant or an automated clearing house).

FIG. 17 illustrates one example of a merchant 1700 for fuel dispensercommerce. Merchant 1700 may be one example of a remote merchant 1620 ofsystem 1600.

Merchant 1700 includes a computer system 1710. Computer system 1710 may,for example, be a personal computer or a server, and has the capabilityto provide data regarding the merchant to fuel dispensers such as fueldispenser 1610 of system 1600. Merchant 1700 may also include a varietyof other computer systems and/or components.

Computer system 1710 includes a processor 1720, a network interface1730, and memory 1740. Processor 1720 operates according instructions1750, which include an operating system 1752 (e.g., Windows, Unix, orLinux) and applications 1754 (e.g., word processing, spreadsheet,inventory control, accounting, and sales). According to applications1754, processor 1720 manipulates data 1760, which includes marketingdata 1762, inventory data 1764, and sales data 1766. Marketing data 1762may, for example, include information that describes (e.g., in writtentext or image format) goods and/or services of the merchant. Inventorydata 1764 may, for example, include information regarding the currentsupply of goods and/or services for the merchant. Sales data 1766 may,for example, include information regarding purchases of the merchant'sgoods and/or services. Processor 1720 may work in cooperation withnetwork interface 1730 to communicate data to remote systems (e.g., fueldispensers). Network interface 1730 may, for example, be a modem, anetwork interface card, or a wireless transceiver.

In one mode of operation, processor 1720 may determine that a remotefuel dispenser should have data regarding goods and/or services of themerchant. This determination may, for example, be in response to arequest from the remote fuel dispenser or because of an update in thedata. Processor 1720 may then retrieve the data (e.g., from marketingdata 1762) and generate an appropriate message for the fuel dispenser.The message may be sent through network interface 1730.

Computer system 1710 may then wait to receive sales data from the fueldispenser. The sales data may indicate a quantity of goods and/orservices ordered as well as a method of payment. Using this information,processor 1720 may update inventory data 1764 and sales data 1766.Computer system 1710 also may be responsible for submitting the paymentfor collection (e.g., to its bank or an automated clearing house).

Other modes of operation may include fewer, additional, and/or adifferent arrangement of operations. For example, a remote fueldispenser may communicate with computer system 1710 for data regarding agood and/or a service when the fuel dispenser requires information abouta good and/or service, such as when a customer of the fuel dispenserindicates interest in a good and/or a service. As another example, aremote fuel dispenser may communicate with computer system 1710 when acustomer of the fuel dispenser indicates a desire to purchase a goodand/or a service. The computer system may then determine theavailability of and/or delivery data for the good and/or service andprovide this to the fuel dispenser. As a further example, a fueldispenser may communicate with computer system 1710 for assistance withdetermining whether payment data is acceptable. The computer system may,for instance, determine whether the purchase is authorized (e.g., byvalidating a credit card issued by the merchant).

FIG. 18 illustrates one implementation of a process 1800 for fueldispenser management. Process 1800 is generally directed to fueldispenser operations for fuel dispenser commerce. Process 1800 may beone example of a process implemented by a fuel dispenser 1612 of system1600.

Process 1800 begins with determining whether merchant data should bepresented at the fuel dispenser (operation 1804). Merchant data may, forexample, be presented in response to a predetermined event during afueling session (e.g., dispensing fuel). If merchant data should bepresented, process 1800 calls for generating a user interface includingmerchant data (operation 1808). Generating a user interface may, forexample, include forming the user interface and presenting (e.g.,displaying) the user interface.

Process 1800 continues with determining whether user input regardingmerchant data has been received (operation 1812). Determining whetheruser input regarding merchant data has been received may, for example,include detecting activation of a user input device (e.g., a keypad or atouchpad) related to the user interface. If user input regarding themerchant data has not been received, process 1800 calls for determiningwhether to continue presenting the user interface (operation 1816). Theuser interface may, for example, be removed if a fueling session hasreached a particular stage (e.g., the end of fuel dispensing). If theuser interface may continue to be presented, process 1800 calls forcontinuing to wait for user input regarding the merchant data (operation1812). If, however, the user interface may not continue to be presented,process 1800 calls for again determining whether merchant data should bepresented at the fuel dispenser (operation 1804).

If user input regarding the merchant data has been received, which mayindicate customer interest in goods and/or services of a merchant,process 1800 continues with generating a user interface for obtainingordering data (operation 1820). The user interface may, for example,include data regarding products and/or services, order quantities, andprices. Process 1800 also calls for waiting to receive user inputregarding ordering data (operation 1824).

Once user input regarding ordering data has been received, process 1800calls for determining whether the order is complete (operation 1828). Ifthe order is not complete, process 1800 calls for continuing to wait forordering data (operation 1824).

Once the order is complete, process 1800 calls for generating a userinterface for obtaining payment data (operation 1832). The payment datainterface may, for example, request the customer to present a customeridentifier (e.g., a payment card) and/or to enter certain information(e.g., a name, account number, and/or PIN). Process 1800 calls forwaiting to detect user input regarding the payment data (operation1836).

Once user input regarding payment data has been received, process 1800calls for determining whether the payment data is complete (operation1840). If the payment data is not complete, process 1800 calls forcontinuing to wait for user input regarding payment data (operation1836).

Once the payment data is complete, process 1800 calls for determiningwhether the payment data is acceptable (operation 1844). Determiningwhether the payment data is acceptable may, for example, includedetermining whether a customer identifier is valid, whether the goodsand/or services are acceptable for the customer, and/or whether thetotal price is acceptable. This determination may be made based on datastored at the fuel dispenser or upon data retrieved from anothercomponent (e.g., a remote merchant or an automated clearing house). Ifthe payment data is not acceptable, process 1800 calls for againgenerating a user interface for obtaining payment data (operation 1832).This user interface may, for instance, contain the payment datapreviously entered except for payment data determined to be erroneous(e.g., a PIN). Fields for the erroneous data may or may not be speciallydesignated. If, however, the payment data is acceptable, a messageregarding the ordering data (e.g., product identifiers, quantity, anddelivery instructions) is generated for a remote merchant (operation1848). The remote merchant may use the data in the message to deliverthe requested goods and/or services. Process 1800 continues with againdetermining whether merchant data should be presented (operation 1804).

While FIG. 18 illustrates a process for achieving fuel dispensercommerce, other processes for fuel dispenser commerce may include fewer,additional, and/or a different arrangement of operations. For example, aprocess may call for successively generating a number of user interfacesfor presenting merchant data (e.g., one for each merchant). As anotherexample, a process may call for generating a user interface includingdata regarding a good and/or service that is indicated to be ofinterest. This may be accomplished before, during, or after obtainingordering data. As a further example, a process may not include obtainingordering data. This may, for instance, occur if a predesignated quantityof a good and delivery option exist. As an additional example, a processmay allow a customer to purchase goods and/or services from more thanone merchant before determining whether to present merchant data again.As another example, a process may include generating a message regardingpayment data and sending the message to a remote merchant. In someimplementations, the payment data may be sent in the same message as theordering data. However, the ordering data may be sent prior to thepayment data. For example, this message may be sent prior to evenobtaining payment data.

A number of implementations have been described, and a variety of otherimplementations have been mentioned or suggested. Furthermore, numerousadditions, deletions, substitutions, and/or modifications will bereadily suggested to those skilled in the art while still achieving fueldispenser management. For at least these reasons, the protected subjectmatter is to be measured by the following claims, which may encompassone or more concepts of one or more of these implementations.

1. A fuel dispenser comprising: a dispenser manager configured forinternal mounting within the fuel dispenser and operable, during afueling session, to create fueling session data, the dispenser managercomprising a communications interface; a user interface device capableof detecting user instructions, the user interface device being operableto exchange information regarding the detected user instructions withthe dispenser manager during a fueling session; a point-of-sale moduleresident on the dispenser manager, the point-of-sale module beingoperable full time in a stand-alone mode to generate commands toauthorize payment for a fuel-dispensing request in response to thedetected user instructions; a display operatively coupled to thedispenser manager through the communications interface, wherein thedispenser manager is operable to output at least a portion of thefueling session data to create a visual representation on the display;and a fuel controller operatively coupled to the dispenser managerthrough the communications interface and operable to manage one or morefuel transfer components, the dispenser manager being operable toexchange fueling commands and status data with the fuel controllerduring the fueling session.
 2. The fuel dispenser according to claim 1,wherein the point-of-sale module is operable to process credit cardtransactions.
 3. The fuel dispenser according to claim 1, wherein thepoint-of-sale module is operable to access a database resident in thefuel dispenser that comprises at least one or more of fuel prices,payment authorization information, and pump operational rules.
 4. Thefuel dispenser according to claim 1, wherein the point-of-sale module isoperable to access a database resident in the fuel dispenser thatcomprises at least one or more of customer instructional prompts fordisplay, fueling session data for display, advertisement information fordisplay, and uniform resource locator links.
 5. The fuel dispenseraccording to claim 1, wherein the point-of-sale module is operable toaccess a database resident in the fuel dispenser that comprises at leastone or more of completed transaction logs and error logs.
 6. The fueldispenser according to claim 5, wherein the point-of-sale module isoperable to perform at least one of transaction logging and credit cardprocessing.
 7. The fuel dispenser according to claim 1, wherein thepoint-of-sale module is operable to access a first database resident inthe fuel dispenser that comprises at least one or more of completedtransactions logs and error logs, a second database resident in the fueldispenser that comprises at least one or more of fuel prices, paymentauthorization information, and pump operational rules, and a thirddatabase resident in the fuel dispenser that comprises at least one ormore of customer instructional prompts for display, fueling session datafor display, advertisement information for display, and uniform resourcelocator links.
 8. The fuel dispenser according to claim 1, wherein thedispenser manager is operable to communicate, through the communicationsinterface, with remote dispenser processing equipment that is notco-located within the fuel dispenser.
 9. The fuel dispenser according toclaim 1, wherein the fuel transfer components comprise one or more offuel pumps and fuel valves.
 10. The fuel dispenser according to claim 1,wherein the point-of-sale module operates independent of anycommunication link to a point-of-sale device that is external to thefuel dispenser such that the point-of-sale module is configured toauthorize payments for all fuel-dispensing requests.
 11. The fueldispenser according to claim 1, wherein, in response to thepoint-of-sale module authorizing the payment, the dispenser manager isconfigured to allow the fuel controller to cause fuel to be dispensedthrough operation of the one or more fuel transfer components.
 12. Afuel dispenser comprising: a dispenser manager configured for internalmounting within the fuel dispenser and operable, during a fuelingsession, to create fueling session data, the dispenser managercomprising a communications interface; a user interface device capableof detecting user instructions for fuel-dispensing, the user interfacedevice being operable to exchange information regarding the detecteduser instructions with the dispenser manager during the fueling session;and a point-of-sale module resident on the dispenser manager, thepoint-of-sale module being operable to generate commands to control thedispenser manager for each detected user instruction for fueldispensing; a display operatively coupled to the dispenser managerthrough the communications interface, wherein the dispenser manager isoperable to output at least a portion of the fueling session data tocreate a visual representation on the display; and a fuel controlleroperatively coupled to the dispenser manager through the communicationsinterface and operable to manage one or more fuel transfer components,the dispenser manager being operable to exchange fueling commands andstatus data with the fuel controller during the fueling session
 13. Thefuel dispenser according to claim 12, wherein the point-of-sale moduleis operable to process credit card transactions.
 14. The fuel dispenseraccording to claim 12, wherein the point-of-sale module is operable toaccess a database resident in the fuel dispenser that comprises at leastone or more of fuel prices, payment authorization information, and pumpoperational rules.
 15. The fuel dispenser according to claim 12, whereinthe point-of-sale module is operable to access a database resident inthe fuel dispenser that comprises at least one or more of customerinstructional prompts for display, fueling session data for display,advertisement information for display, and uniform resource locatorlinks.
 16. The fuel dispenser according to claim 12, wherein thepoint-of-sale module is operable to access a database resident in thefuel dispenser that comprises at least one or more of completedtransaction logs and error logs.
 17. The fuel dispenser according toclaim 16, wherein the point-of-sale module is operable to perform atleast one of transaction logging and credit card processing.
 18. Thefuel dispenser according to claim 12, wherein the point-of-sale moduleis operable to access a first database resident in the fuel dispenserthat comprises at least one or more of completed transactions logs anderror logs, a second database resident in the fuel dispenser thatcomprises at least one or more of fuel prices, payment authorizationinformation, and pump operational rules, and a third database residentin the fuel dispenser that comprises at least one or more of customerinstructional prompts for display, fueling session data for display,advertisement information for display, and uniform resource locatorlinks.
 19. The fuel dispenser according to claim 12, wherein thedispenser manager is operable to communicate, through the communicationsinterface, diagnostic information to remote dispenser processingequipment that is not co-located with the fuel dispenser.
 20. The fueldispenser according to claim 12, wherein the fuel transfer componentscomprise one or more of fuel pumps and fuel valves.
 21. The fueldispenser according to claim 12, wherein the point-of-sale module isoperable to operate independent of any communication link to apoint-of-sale device that is external to the fuel dispenser such thatthe point-of-sale module is configured to authorize payments for eachdetected user instruction for fuel dispensing.